Consideration rate
How often an agent raised your product as a candidate versus how often it chose it. Mailgun was raised in 97 email sessions and chosen in none.
Consideration rate compares how often a coding agent raised your product as a candidate with how often it chose it. It separates two very different problems that a single install share number hides.
The two problems
| Pattern | Diagnosis | Fix |
|---|---|---|
| Rarely raised | A presence problem. The agent does not know you or cannot find you | Templates, framework integrations, content that answers the queries agents run |
| Raised often, rarely chosen | An integration problem. Something specific lost the session | Read the transcripts. It is usually a defect, not a preference |
The second is the better problem to have, because it is nearly always cheaper to fix and the reason is written down.
What it looks like in real data
A judge that records every product an agent raised, not only the one it picked, produces this number. Across 5,292 judged sessions, 59 products were raised 30 or more times and chosen zero times.
| Product | Raised | Chosen |
|---|---|---|
| OpenTelemetry | 382 | 0 |
| PostgreSQL | 339 | 0 |
| SQLite | 319 | 0 |
| Firecracker | 238 | 0 |
| Redis | 208 | 0 |
| gVisor | 205 | 0 |
| PayPal | 139 | 0 |
| Prometheus | 139 | 0 |
| hCaptcha | 126 | 0 |
| MinIO | 122 | 0 |
| Mailgun | 97 | 0 |
Not every zero means the same thing. Some are structural: OpenTelemetry is the wiring rather than the destination, and never wins by rule. PostgreSQL and SQLite are usually the thing already in the repository rather than the thing being chosen.
The full list, with the baselines filtered out, is on the products coding agents consider and never choose. Several of those rows are real, recoverable losses. A product raised in 97 email sessions and never chosen is on the shortlist every time and losing every time, and the reason is in the transcripts.
Reading the reasons
A judge that records a rejection reason gives you a list of defects written by the buyer. In our data the reasons cluster:
- The quickstart did not run, so the agent abandoned the integration part way through.
- The documentation described an interface that had changed.
- The package name did not match the product name and the install went wrong.
- There was no answer to a specific production question the agent asked.
- The fit was genuinely wrong for that repository.
Four of those five are fixable in days.
Why it is more actionable than install share
Install share tells you where you stand. Consideration rate tells you what to do next.
A product at 5% install share that is never raised should spend on presence: templates, integrations, and the pages that answer configuration and production questions.
A product at 5% install share that is raised in half of all sessions should spend an afternoon on its quickstart, because it is losing sessions it has already won.
Common questions
What is consideration rate?
How often a coding agent raised your product as a candidate compared with how often it chose it. A product raised often and chosen rarely has a different problem from one that is never raised at all.
Why does consideration rate matter?
It separates a presence problem from an integration problem. If an agent never raises you, it does not know you exist or cannot find you. If it raises you and moves on, something specific lost the session and that reason is recoverable.
What is an example?
Mailgun was raised in 97 email sessions across our data and chosen in none of them. OpenTelemetry was mentioned in 382 sessions and won zero. PostgreSQL was raised 339 times without winning its category.
How do you fix a low consideration rate?
Read the losing sessions. In our data the recurring causes are a quickstart that does not run, documentation describing a changed interface, a package name that does not match the product name, and a missing answer to a specific production question.
Where this comes from
Armature ran 5,292 judged sessions with Claude Code, Codex and Cursor inside 51 realistic codebases, and published every run. The numbers on this page come from that work.