Buy Crypto- Markets
Futures- Spot
- Copy Trade
- Earn
- More
Lean Harness, Fat Skill: The Real Source of 100x AI Productivity
Original Article Title: Thin Harness, Fat Skills
Original Article Author: Garry Tan
Translation: Peggy, BlockBeats
Editor's Note: As "stronger models" become the default answer in the industry, this article provides a different perspective: what truly widens productivity gaps by 10x, 100x, or even 1000x is not the model itself, but a whole system design built around the model.
The author of this article, Garry Tan, current President and CEO of Y Combinator, has long been involved in AI and early-stage startup ecosystems. He introduces the "fat skills + thin harness" framework, breaking down AI applications into key components such as skills, runtime framework, context routing, task division, and knowledge compression.
In this system, the model is no longer the entire capability but merely an execution unit within the system. What truly determines output quality is how you organize context, solidify processes, and delineate the boundary between "inference" and "computation."
More importantly, this approach is not merely conceptual but has been validated in real scenarios: faced with data processing and matching tasks from thousands of entrepreneurs, the system achieves capabilities close to human analysts through a "read-summarize-infer-write back" loop, continuously self-optimizing without the need for code rewrites. This "learning system" transforms AI from a one-off tool to an infrastructure with a compounding effect.
Thus, the core reminder provided in the article becomes clear: in the AI era, efficiency gaps are no longer determined by whether you use the most advanced model but by whether you have built a system that can continuously accumulate capabilities and evolve automatically.
The following is the original text:
Steve Yegge said that those using AI programming agents are "10 to 100 times more efficient than engineers who only code with a cursor and chat tools, roughly 1000 times more efficient than a 2005 Google engineer."
Note: Steve Yegge is a highly influential software engineer, technical blogger, and engineering culture commentator in Silicon Valley, known for his sharp, lengthy, and strongly opinionated technical articles. He has served as a senior engineer at companies such as Amazon and Google, later joining Salesforce, then moving to startups in the AI space, and also being one of the early advocates of the Dart project.
This is not an exaggeration. I have seen it with my own eyes and experienced it firsthand. However, when people hear about such a gap, they often attribute it to the wrong factors: a stronger model, a smarter Claude, more parameters.
In reality, the person who is twice as efficient and the one who is a hundred times more efficient are using the same model. The difference is not in "intelligence" but in "architecture," and this architecture is so simple that it can fit on a notecard.
The Harness (Execution Framework) is the Product Itself.
On March 31, 2026, in an unexpected turn of events, Anthropic accidentally released the complete source code of the Claude Code to npm—totaling 512,000 lines. I read through it all. This validated something I have always talked about at YC (Y Combinator): the real secret is not in the model but in the "layer that wraps the model."
Real-time codebase context, Prompt cache, tools designed for specific tasks, maximum compression of redundant context, structured session memory, parallel-running subagents—none of these make the model smarter. But they can provide the model with the "right context" at the "right time," while avoiding being overwhelmed by irrelevant information.
This wrapping layer is called the harness (execution framework). And the real question all AI builders should ask is: What should go into the harness, and what should stay outside?
Interestingly, this question has a very specific answer—a thin harness, fat skills.
Five Definitions
The bottleneck has never been in the intelligence of the model. The model already knows how to reason, synthesize information, and write code.
They fail because they do not understand your data—your schema, your agreements, what shape your problem takes. And the following five definitions are precisely designed to address this issue.
1. Skill File
A skill file is a reusable markdown document that teaches the model "how to do something." Note that it does not tell it "what to do"—that part is provided by the user. The skill file provides the process.
The key point that most people overlook is this: a skill file is actually like a method call. It can take parameters. You can call it with different parameters. The same process, when called with different inputs, can demonstrate vastly different capabilities.
For example, there is a skill called /investigate. It consists of seven steps: Define data scope, Build timeline, Diarize each document, Synthesize, Argue from both sides, Cite sources. It takes three parameters: TARGET, QUESTION, and DATASET.
If you point it at a security scientist and 2.1 million forensic emails, it will turn into a medical research analyst to determine if a whistleblower has been suppressed.
If you point it at a shell company and the Federal Election Commission (FEC) disclosure filings, it will transform into a litigation forensics investigator to trace coordinated political donations.
Same skill. Same seven steps. Same markdown file. The skill describes a decision-making process, and what actually brings it to life is the input parameters at runtime.
This is not prompt engineering but software design: only here, markdown is the programming language, and human judgment is the runtime environment. In fact, markdown is even more suitable for encapsulation than rigid source code because it describes the process, judgment, and context, which happen to be the language the model understands best.
2. Harness (Runtime Framework)
Harness is the layer of software that drives the LLM's operation. It only does four things: run the model in a loop, read and write your files, manage context, and enforce safety constraints.
That's it. That's "thin."
The opposite pattern is: fat harness, thin skills.
You've probably seen this: over 40 tool definitions, where the documentation alone takes up half the screen; an all-powerful God-tool that takes 2 to 5 seconds roundtrip to the Controllable Data Generator; or wrapping every endpoint of a REST API into a separate tool. The result is triple the token usage, triple the latency, and triple the failure rate.
The truly ideal approach is to use purpose-built tools that are fast and narrowly focused.
For example, a Playwright CLI that takes only 100 milliseconds for each browser operation; not a Chrome MCP that takes 15 seconds to do a screenshot → find → click → wait → read. The former is 75 times faster.
Modern software no longer needs to be "over-engineered." What you should do is: only build what you truly need and nothing more.
3. Resolver
A resolver is essentially a context routing table. When task type X occurs, document Y is loaded as a priority. Skills tell the model "how to do"; resolvers tell the model "when to load what."
For example, a developer changes a certain prompt. Without a resolver, they might just finish the change and release it right away. With a resolver, the model would first read docs/EVALS.md. This document would say: run the evaluation suite first, compare scores before and after; if accuracy drops by more than 2%, roll back and investigate the reason. This developer may not have even known about the existence of the evaluation suite. It is the resolver that loads the right context at the right time.
Claude Code comes with a built-in resolver. Each skill has a description field, and the model automatically matches the user's intent to the skill's description. You don't even need to remember whether the /ship skill exists—the description itself is the resolver.
To be honest, my previous CLAUDE.md was a whopping 20,000 lines long. Every quirk, every pattern, every lesson I had learned was crammed into it. Utterly absurd. The model's attention quality significantly decreased. Claude Code even directly told me to get rid of it.
The final fix was probably only 200 lines—keeping only a few document pointers. Let the resolver load the necessary document at the crucial moment. This way, 20,000 lines of knowledge can still be accessed when needed without polluting the context window.
4. Latent and Deterministic
In your system, every step is either in this category or that. And confusing these two is the most common mistake in agent design.
· Latent space is where intelligence resides. The model reads, understands, judges, and decides here. It deals with: judgment, synthesis, pattern recognition.
· Deterministic is where trustworthiness resides. Same input, always the same output. SQL queries, compiled code, arithmetic operations all belong to this side.
A single LLM can help you seat 8 people for a dinner party, taking into account each person's personality and social dynamics. But if you ask it to seat 800 people, it will earnestly generate a "seemingly reasonable but actually completely wrong" seating chart. Because it's no longer a matter of potential space that needs handling, but a deterministic problem that has been forcibly squeezed into the latent space—a combinatorial optimization problem.
The worst systems always misplace the work on either side of this boundary. The best systems, however, will starkly delineate the boundary.
5. Diarization (Document Clustering / Topic Portraiture)
This diarization step is what truly gives AI the ability to produce value in working with real-world knowledge.
It means: the model reads through all materials related to a topic, then produces a structured portrait. Condensing judgments from dozens or even hundreds of documents onto a single page.
This is not something an SQL query can produce. Nor is it something an RAG pipeline can produce. The model must actually read, hold contradictory information in mind simultaneously, note what changed, when it changed, and then synthesize these contents into structured intelligence.
This is the difference between a database query and an analyst briefing.
This Architecture
These five concepts can be combined into a very simple three-layer architecture.
· The top layer is Fat Skills: processes written in markdown, carrying judgments, methodologies, and domain knowledge. 90% of the value resides in this layer.
· The middle layer is a thin CLI harness: about 200 lines of code, taking JSON input, producing text output, defaulting to read-only.
· The bottom layer is your application system: QueryDB, ReadDoc, Search, Timeline—these are deterministic infrastructure.
The guiding principle is directional: push "intelligence" as high up as possible into skills; push "execution" as far down as possible into deterministic tools; keep the harness light.
The result is: every time the model's capabilities improve, all skills automatically become stronger; while the foundational deterministic systems remain stable and reliable.
Learning Systems
Below, I will use a real system we are building at YC to show how these five definitions work together.
In July 2026, Chase Center. Startup School has 6000 founders in attendance. Everyone has structured application materials, questionnaire responses, transcripts of 1:1 mentor conversations, and public signals: posts on X, GitHub commit history, and usage of Claude Code (indicating their development speed).
The traditional approach is for a 15-person project team to read applications one by one, make intuitive judgments, and then update a spreadsheet.
This method can work with 200 people, but it completely fails with 6000 people. No human can hold so many profiles in their mind and realize that the AI agent infrastructure suggests the top three candidates for direction: the founder of a development tool in Lagos, a compliance entrepreneur in Singapore, and a CLI tool developer in Brooklyn—each of whom, in different 1:1 conversations, described the same pain point using completely different expressions.
The model can do it. Here's how:
Enrichment
There is a skill called /enrich-founder, which pulls from all data sources, performs enrichment, diarization, and highlights the difference between "what the founder said" and "what they are actually doing."
The underlying deterministic system handles: SQL queries, GitHub data, browser tests of Demo URLs, social signal extraction, CrustData queries, etc. A scheduled task runs once a day. The profiles of 6000 founders are always up to date.
The output of diarization can capture information that keyword searches could never find:
Founder: Maria Santos Company: Contrail (contrail.dev) Self-description: "Datadog for AI agent" Actual activity: 80% of code commits are focused on the billing module → Essentially building a FinOps tool disguised as an observability tool
This difference between "what is said and what is done" requires reading GitHub commit histories, application materials, and conversation records simultaneously and integrating them mentally. No embedding similarity search or keyword filtering can achieve this. The model must read in full and then make judgments. (This is exactly the kind of task that should be in the latent space!)
Matching
This is where "skill = method invocation" shines.
With the same matching skill, calling it three times can result in completely different strategies:
/match-breakout: Handle 1200 people, cluster by domain, group of 30 each (embedding + deterministic assignment)
/match-lunch: Handle 600 people, cross-domain "randomized matching," 8 people per table without repetition — LLM first generates topics, then a deterministic algorithm arranges the seats
/match-live: Handle live on-site participants, based on nearest neighbor embedding, complete 1-on-1 matching within 200ms, and exclude people who have already met
The model can also make judgments that traditional clustering algorithms cannot achieve:
"Both Santos and Oram fall under AI infrastructure, but they are not in a competitive relationship — Santos does cost attribution, Oram does orchestration. They should be placed in the same group."
"Kim's application stated developer tools, but the 1:1 conversation revealed they are working on SOC2 compliance automation. Should be reclassified under FinTech / RegTech."
This kind of reclassification is completely missed by embeddings. The model must read the entire profile.
Learning Loop
After the event, an /improve skill reads the NPS survey results, conducts diarization on those feedback categorized as "okay, but could be better" — not negative reviews, but those that are almost there — and extracts patterns.
It then proposes new rules and writes them back into the matching skill:
When a participant mentions "AI infrastructure," but over 80% of their code is for billing:
→ Categorized as FinTech, not AI Infra
When two people in the same group already know each other:
→ Reduce matching weight
Prioritize introducing new relationships
These rules are written back to the skill file. They take effect automatically on the next run. Skills are "self-editing." In the July event, "okay, but could be better" ratings accounted for 12%; in the next event, it dropped to 4%.
The skill file learns what "okay" means, and the system gets better without anyone rewriting the code.
This pattern can be migrated to any field:
Retrieve → Read → Diarize → Count → Synthesize
Then: Research → Investigate → Diarize → Rewrite skill
If you were to ask what the most valuable loop of 2026 is, it's this one. It can be applied to almost any knowledge work scenario.
Skill is a Permanent Upgrade
I recently posted a command to OpenClaw on X, which received a much bigger response than expected:
Prompt: You are not allowed to do one-off work. If I ask you to do something that will repeat in the future, you must: manually process the first time 3 to 10 samples, show me the results; If I approve, turn it into a skill file; If it should run automatically, add it to the scheduled task. The criterion is: If I need to ask a second time, you have failed.
This content received thousands of likes and over two thousand bookmarks. Many people thought this was a prompt engineering technique.
Actually, it's not. It's the architecture mentioned above. Every skill you write is a permanent upgrade to the system. It won't degrade, won't be forgotten. It will run automatically at three in the morning. And when the next generation model is released, all skills will instantly become stronger—the judgment ability of the latent part improves, while the deterministic part remains stable and reliable.
This is where Yegge's 100x efficiency comes from.
Not from smarter models, but from: Thick Skills, Thin Harness, and the discipline of solidifying everything into capabilities.
The system will grow exponentially. Build once, run long-term.
You may also like
1 billion DOTs were minted out of thin air, but the hacker only made 230,000 dollars
After the blockade of the Strait of Hormuz, when will the war end?
Before using Musk's "Western WeChat" X Chat, you need to understand these three questions
The X Chat will be available for download on the App Store this Friday. The media has already covered the feature list, including self-destructing messages, screenshot prevention, 481-person group chats, Grok integration, and registration without a phone number, positioning it as the "Western WeChat." However, there are three questions that have hardly been addressed in any reports.
There is a sentence on X's official help page that is still hanging there: "If malicious insiders or X itself cause encrypted conversations to be exposed through legal processes, both the sender and receiver will be completely unaware."
No. The difference lies in where the keys are stored.
In Signal's end-to-end encryption, the keys never leave your device. X, the court, or any external party does not hold your keys. Signal's servers have nothing to decrypt your messages; even if they were subpoenaed, they could only provide registration timestamps and last connection times, as evidenced by past subpoena records.
X Chat uses the Juicebox protocol. This solution divides the key into three parts, each stored on three servers operated by X. When recovering the key with a PIN code, the system retrieves these three shards from X's servers and recombines them. No matter how complex the PIN code is, X is the actual custodian of the key, not the user.
This is the technical background of the "help page sentence": because the key is on X's servers, X has the ability to respond to legal processes without the user's knowledge. Signal does not have this capability, not because of policy, but because it simply does not have the key.
The following illustration compares the security mechanisms of Signal, WhatsApp, Telegram, and X Chat along six dimensions. X Chat is the only one of the four where the platform holds the key and the only one without Forward Secrecy.
The significance of Forward Secrecy is that even if a key is compromised at a certain point in time, historical messages cannot be decrypted because each message has a unique key. Signal's Double Ratchet protocol automatically updates the key after each message, a mechanism lacking in X Chat.
After analyzing the X Chat architecture in June 2025, Johns Hopkins University cryptology professor Matthew Green commented, "If we judge XChat as an end-to-end encryption scheme, this seems like a pretty game-over type of vulnerability." He later added, "I would not trust this any more than I trust current unencrypted DMs."
From a September 2025 TechCrunch report to being live in April 2026, this architecture saw no changes.
In a February 9, 2026 tweet, Musk pledged to undergo rigorous security tests of X Chat before its launch on X Chat and to open source all the code.
As of the April 17 launch date, no independent third-party audit has been completed, there is no official code repository on GitHub, the App Store's privacy label reveals X Chat collects five or more categories of data including location, contact info, and search history, directly contradicting the marketing claim of "No Ads, No Trackers."
Not continuous monitoring, but a clear access point.
For every message on X Chat, users can long-press and select "Ask Grok." When this button is clicked, the message is delivered to Grok in plaintext, transitioning from encrypted to unencrypted at this stage.
This design is not a vulnerability but a feature. However, X Chat's privacy policy does not state whether this plaintext data will be used for Grok's model training or if Grok will store this conversation content. By actively clicking "Ask Grok," users are voluntarily removing the encryption protection of that message.
There is also a structural issue: How quickly will this button shift from an "optional feature" to a "default habit"? The higher the quality of Grok's replies, the more frequently users will rely on it, leading to an increase in the proportion of messages flowing out of encryption protection. The actual encryption strength of X Chat, in the long run, depends not only on the design of the Juicebox protocol but also on the frequency of user clicks on "Ask Grok."
X Chat's initial release only supports iOS, with the Android version simply stating "coming soon" without a timeline.
In the global smartphone market, Android holds about 73%, while iOS holds about 27% (IDC/Statista, 2025). Of WhatsApp's 3.14 billion monthly active users, 73% are on Android (according to Demand Sage). In India, WhatsApp covers 854 million users, with over 95% Android penetration. In Brazil, there are 148 million users, with 81% on Android, and in Indonesia, there are 112 million users, with 87% on Android.
WhatsApp's dominance in the global communication market is built on Android. Signal, with a monthly active user base of around 85 million, also relies mainly on privacy-conscious users in Android-dominant countries.
X Chat circumvented this battlefield, with two possible interpretations. One is technical debt; X Chat is built with Rust, and achieving cross-platform support is not easy, so prioritizing iOS may be an engineering constraint. The other is a strategic choice; with iOS holding a market share of nearly 55% in the U.S., X's core user base being in the U.S., prioritizing iOS means focusing on their core user base rather than engaging in direct competition with Android-dominated emerging markets and WhatsApp.
These two interpretations are not mutually exclusive, leading to the same result: X Chat's debut saw it willingly forfeit 73% of the global smartphone user base.
This matter has been described by some: X Chat, along with X Money and Grok, forms a trifecta creating a closed-loop data system parallel to the existing infrastructure, similar in concept to the WeChat ecosystem. This assessment is not new, but with X Chat's launch, it's worth revisiting the schematic.
X Chat generates communication metadata, including information on who is talking to whom, for how long, and how frequently. This data flows into X's identity system. Part of the message content goes through the Ask Grok feature and enters Grok's processing chain. Financial transactions are handled by X Money: external public testing was completed in March, opening to the public in April, enabling fiat peer-to-peer transfers via Visa Direct. A senior Fireblocks executive confirmed plans for cryptocurrency payments to go live by the end of the year, holding money transmitter licenses in over 40 U.S. states currently.
Every WeChat feature operates within China's regulatory framework. Musk's system operates within Western regulatory frameworks, but he also serves as the head of the Department of Government Efficiency (DOGE). This is not a WeChat replica; it is a reenactment of the same logic under different political conditions.
The difference is that WeChat has never explicitly claimed to be "end-to-end encrypted" on its main interface, whereas X Chat does. "End-to-end encryption" in user perception means that no one, not even the platform, can see your messages. X Chat's architectural design does not meet this user expectation, but it uses this term.
X Chat consolidates the three data lines of "who this person is, who they are talking to, and where their money comes from and goes to" in one company's hands.
The help page sentence has never been just technical instructions.
Parse Noise's newly launched Beta version, how to "on-chain" this heat?
Is Lobster a Thing of the Past? Unpacking the Hermes Agent Tools that Supercharge Your Throughput to 100x
Declare War on AI? The Doomsday Narrative Behind Ultraman's Residence in Flames
Crypto VCs Are Dead? The Market Extinction Cycle Has Begun
Claude's Journey to Foolishness in Diagrams: The Cost of Thriftiness, or How API Bill Increased 100-Fold
Edge Land Regress: A Rehash Around Maritime Power, Energy, and the Dollar
Arthur Hayes Latest Interview: How Should Retail Investors Navigate the Iran Conflict?
Just now, Sam Altman was attacked again, this time by gunfire
Straits Blockade, Stablecoin Recap | Rewire News Morning Edition
From High Expectations to Controversial Turnaround, Genius Airdrop Triggers Community Backlash
The Xiaomi electric vehicle factory in Beijing's Daxing district has become the new Jerusalem for the American elite
Ultraman is not afraid of his mansion being attacked; he has a fortress.
US-Iran Negotiations Collapse, Bitcoin Faces Battle to Defend $70,000 Level
Reflections and Confusions of a Crypto VC
Morning News | Ether Machine terminates $1.6 billion SPAC deal; SpaceX holds approximately $603 million in Bitcoin; Michael Saylor releases Bitcoin Tracker information again
1 billion DOTs were minted out of thin air, but the hacker only made 230,000 dollars
After the blockade of the Strait of Hormuz, when will the war end?
Before using Musk's "Western WeChat" X Chat, you need to understand these three questions
The X Chat will be available for download on the App Store this Friday. The media has already covered the feature list, including self-destructing messages, screenshot prevention, 481-person group chats, Grok integration, and registration without a phone number, positioning it as the "Western WeChat." However, there are three questions that have hardly been addressed in any reports.
There is a sentence on X's official help page that is still hanging there: "If malicious insiders or X itself cause encrypted conversations to be exposed through legal processes, both the sender and receiver will be completely unaware."
No. The difference lies in where the keys are stored.
In Signal's end-to-end encryption, the keys never leave your device. X, the court, or any external party does not hold your keys. Signal's servers have nothing to decrypt your messages; even if they were subpoenaed, they could only provide registration timestamps and last connection times, as evidenced by past subpoena records.
X Chat uses the Juicebox protocol. This solution divides the key into three parts, each stored on three servers operated by X. When recovering the key with a PIN code, the system retrieves these three shards from X's servers and recombines them. No matter how complex the PIN code is, X is the actual custodian of the key, not the user.
This is the technical background of the "help page sentence": because the key is on X's servers, X has the ability to respond to legal processes without the user's knowledge. Signal does not have this capability, not because of policy, but because it simply does not have the key.
The following illustration compares the security mechanisms of Signal, WhatsApp, Telegram, and X Chat along six dimensions. X Chat is the only one of the four where the platform holds the key and the only one without Forward Secrecy.
The significance of Forward Secrecy is that even if a key is compromised at a certain point in time, historical messages cannot be decrypted because each message has a unique key. Signal's Double Ratchet protocol automatically updates the key after each message, a mechanism lacking in X Chat.
After analyzing the X Chat architecture in June 2025, Johns Hopkins University cryptology professor Matthew Green commented, "If we judge XChat as an end-to-end encryption scheme, this seems like a pretty game-over type of vulnerability." He later added, "I would not trust this any more than I trust current unencrypted DMs."
From a September 2025 TechCrunch report to being live in April 2026, this architecture saw no changes.
In a February 9, 2026 tweet, Musk pledged to undergo rigorous security tests of X Chat before its launch on X Chat and to open source all the code.
As of the April 17 launch date, no independent third-party audit has been completed, there is no official code repository on GitHub, the App Store's privacy label reveals X Chat collects five or more categories of data including location, contact info, and search history, directly contradicting the marketing claim of "No Ads, No Trackers."
Not continuous monitoring, but a clear access point.
For every message on X Chat, users can long-press and select "Ask Grok." When this button is clicked, the message is delivered to Grok in plaintext, transitioning from encrypted to unencrypted at this stage.
This design is not a vulnerability but a feature. However, X Chat's privacy policy does not state whether this plaintext data will be used for Grok's model training or if Grok will store this conversation content. By actively clicking "Ask Grok," users are voluntarily removing the encryption protection of that message.
There is also a structural issue: How quickly will this button shift from an "optional feature" to a "default habit"? The higher the quality of Grok's replies, the more frequently users will rely on it, leading to an increase in the proportion of messages flowing out of encryption protection. The actual encryption strength of X Chat, in the long run, depends not only on the design of the Juicebox protocol but also on the frequency of user clicks on "Ask Grok."
X Chat's initial release only supports iOS, with the Android version simply stating "coming soon" without a timeline.
In the global smartphone market, Android holds about 73%, while iOS holds about 27% (IDC/Statista, 2025). Of WhatsApp's 3.14 billion monthly active users, 73% are on Android (according to Demand Sage). In India, WhatsApp covers 854 million users, with over 95% Android penetration. In Brazil, there are 148 million users, with 81% on Android, and in Indonesia, there are 112 million users, with 87% on Android.
WhatsApp's dominance in the global communication market is built on Android. Signal, with a monthly active user base of around 85 million, also relies mainly on privacy-conscious users in Android-dominant countries.
X Chat circumvented this battlefield, with two possible interpretations. One is technical debt; X Chat is built with Rust, and achieving cross-platform support is not easy, so prioritizing iOS may be an engineering constraint. The other is a strategic choice; with iOS holding a market share of nearly 55% in the U.S., X's core user base being in the U.S., prioritizing iOS means focusing on their core user base rather than engaging in direct competition with Android-dominated emerging markets and WhatsApp.
These two interpretations are not mutually exclusive, leading to the same result: X Chat's debut saw it willingly forfeit 73% of the global smartphone user base.
This matter has been described by some: X Chat, along with X Money and Grok, forms a trifecta creating a closed-loop data system parallel to the existing infrastructure, similar in concept to the WeChat ecosystem. This assessment is not new, but with X Chat's launch, it's worth revisiting the schematic.
X Chat generates communication metadata, including information on who is talking to whom, for how long, and how frequently. This data flows into X's identity system. Part of the message content goes through the Ask Grok feature and enters Grok's processing chain. Financial transactions are handled by X Money: external public testing was completed in March, opening to the public in April, enabling fiat peer-to-peer transfers via Visa Direct. A senior Fireblocks executive confirmed plans for cryptocurrency payments to go live by the end of the year, holding money transmitter licenses in over 40 U.S. states currently.
Every WeChat feature operates within China's regulatory framework. Musk's system operates within Western regulatory frameworks, but he also serves as the head of the Department of Government Efficiency (DOGE). This is not a WeChat replica; it is a reenactment of the same logic under different political conditions.
The difference is that WeChat has never explicitly claimed to be "end-to-end encrypted" on its main interface, whereas X Chat does. "End-to-end encryption" in user perception means that no one, not even the platform, can see your messages. X Chat's architectural design does not meet this user expectation, but it uses this term.
X Chat consolidates the three data lines of "who this person is, who they are talking to, and where their money comes from and goes to" in one company's hands.
The help page sentence has never been just technical instructions.
App