In-house rate
The share of sessions where a coding agent wrote the implementation itself instead of adopting any product. It ranged from 0% to 56% by category.
In-house rate is the percentage of sessions in a category where a coding agent wrote the implementation itself instead of adopting any product. It is the share of the market that every vendor loses at once.
The range
Across 15,287 judged sessions in 31 categories, the in-house rate went from nothing to more than half.
| Category | In-house rate |
|---|---|
| Performance CI | 56% |
| Evals | 34% |
| Agent frameworks | 25% |
| Search | 24% |
| Serverless | 18% |
| Message queues | 17% |
| Usage-based billing | 20% |
| Product analytics | 14% |
| E-signature | 14% |
| Bot protection | 11% |
| Authentication | 9% |
| Code review | 8% |
| Internationalization | 8% |
| Observability | 7% |
| Maps | 6% |
| Voice agents, AI gateway, AI search | 5% |
| Storage | 3% (8 of 281) |
| Document processing | 1% (12 of 801) |
| Cloud | 1% (2 of 359) |
| 1% (2 of 351) | |
| Payments, deploy, sandboxes, vector search, in-app chat and calls, AI SRE, security testing | 0% (not one session) |
What separates the two ends
Look at the bottom: payments, deploy, sandboxes, vector search, in-app chat and calls, AI SRE, security testing and security platforms, where not one session out of 3,271 ended without a product, plus email, cloud and storage, where the agent wrote it itself in two, two and eight sessions. Each of those needs something an agent cannot write. A merchant account. A machine that stays up. An IP address with a sending reputation.
Now the top: performance testing, evals, agent frameworks and search, the four above 20%, plus usage-based billing at 20%. Each can be started with a script. A benchmark loop. A file of test cases. A LIKE query.
The rule: if the first ten percent of the problem can be solved in fifty lines, an agent will write those fifty lines. It is good at writing fifty lines and it has no budget to consider.
The agent does not know the fifty lines break at volume. It knows the problem looks tractable.
It varies by agent
| Agent | In-house rate |
|---|---|
| Claude Code | 12% |
| Codex | 6% |
| Cursor | 9% |
| Grok Build CLI | 10% |
| Muse Code | 15% |
Claude Code builds rather than adopts more than twice as often as Codex, and Muse Code slightly more often still. That is consistent with another habit: Claude Code ran at least one web search in 28% of its sessions and Muse Code in 43%, against 97% for Codex. An agent that does not look for candidates has fewer of them in front of it, and its own implementation is always available.
Why it changes your content
In a category with a high in-house rate, most vendor content argues the wrong thing.
The usual argument is "we are better than the alternatives", which only matters to somebody who has decided to buy something. In performance testing, 56% of sessions never reached that question.
The argument you need first is that the problem is harder than it looks, and it only works with specifics: the failure modes, the edge cases, what the maintenance costs in year two, each with numbers. Put it in the documentation rather than the blog, because that is where an agent searching a production question will look.
Where to put it in the denominator
In-house sessions belong in your install share denominator. Excluding them makes the number look better and hides the competitor you most need to see.
Common questions
What is the in-house rate?
The percentage of sessions in a category where a coding agent wrote the implementation itself rather than adopting any product. It measures how often the whole vendor category loses to a hand-written script.
Which categories have the highest in-house rate?
Performance testing at 56%, evals at 34%, agent frameworks at 25%, search at 24%, usage-based billing at 20%, then serverless at 18% and message queues at 17%. Payments, databases, deployment, sandboxes, vector search, in-app chat and calls, and AI SRE were all zero.
Why does the in-house rate matter?
It tells you what argument your content has to win. A high rate means you must first show that the problem is harder than it looks. A rate of zero means you are in a straight vendor comparison.
Does the in-house rate depend on the agent?
Yes. Claude Code wrote its own implementation in 12% of all runs, against 6% for Codex, 9% for Cursor, 10% for Grok Build CLI and 15% for Muse Code.
Where this comes from
Armature ran 15,287 judged sessions with Claude Code, Codex, Cursor, Grok Build CLI and Muse Code inside 110 realistic codebases, and published every run. The numbers on this page come from that work.