The products coding agents consider and never choose

The usual way to lose is to be unknown. This page is about the other way, which is more common than people expect and much cheaper to fix.

The finding

The list

Ranked by how often the product was on the table. Eight products are excluded because on their board they are the thing underneath rather than a candidate: PostgreSQL and SQLite, which are the databases already in the panel; Docker, Firecracker and gVisor, the runtimes the sandboxes run on; OpenTelemetry and JWT, which are standards rather than things a vendor sells; and Redis on the cloud board.

That is the top 26 by volume. The full set is 67.

Why this is the better problem to have

Two products with the same install share of zero can be in completely different positions.

A product raised in 97 sessions has already won the hard part. It got into the model's head, it survived the shortlist, and then it lost at a step that is written down.

What loses those sessions

From reading the transcripts, in order of frequency:

The quickstart does not run when pasted. An unstated environment variable, an install step assumed from the previous page, a dashboard action that never appears in code. The agent starts the integration, hits the gap, and switches candidates rather than debugging your documentation.

The documentation describes an interface that changed. The agent writes code that matches the page, and it fails. This is worse than having no documentation, because the failure looks like the product being broken.

The package name does not match the product name. The agent guesses, and the guess installs nothing, an abandoned package, or somebody else's.

A specific production question has no answer. Agents search for configuration options, limits, retention, pricing units and self-hosting specifics. A missing answer reads as a missing capability.

The fit was genuinely wrong. The least common of the five, and the only one that is not a defect. Worth knowing, and worth not confusing with the other four.

The pattern in who raises things

One thing worth flagging, because it changes how to read the table.

Cursor raises more products than the other two agents, consistently. It was the agent that raised the product most often in 59 of the 67 cases. In observability, Cursor named OpenTelemetry in 85% of its sessions against 62% for Claude Code and 57% for Codex.

The plain reading is that Cursor enumerates more alternatives before deciding. That means a Cursor session is a better place to get onto a shortlist and no easier a place to win from, and it means a raise count from Cursor carries less signal than the same count from Codex.

What to do if your product is on this list

1. Get the transcripts. The reason is recorded per session, with a pointer to the file or the line. That is a defect list written by the buyer.
2. Paste your own quickstart into an empty project and run it. This is the most common cause and the cheapest fix. See how to write a quickstart an agent can follow.
3. Check the current version is stated on the page, in the text.
4. Check your product name, package name, import name and CLI command are the same string, or that the mapping is written down.
5. Run the documentation audit. Twenty checks, each testable in minutes.

How this was measured

Because the judge records every product an agent raised and not only the one it picked, this number exists. For each product it records a role, primary pick, alternative, mention or rejected, plus a reason, a code from a fixed vocabulary, a pointer to the evidence and a confidence.

The judge also undercounts, so we track the gap: products a transcript mentions that the judge did not list. In observability, 155 of 360 sessions have at least one. The raise counts here are a floor, not a ceiling.

Full method: how we measured this. Every run is on the sector boards.