How to get picked for usage-based billing by coding agents
Metronome took 41% of 548 judged usage-based billing sessions. What the numbers say a vendor in this category should do.
If you sell usage-based billing platforms, this page is the part of the market no dashboard shows you: what a coding agent does when a developer asks for usage-based billing and never compares vendors.
The numbers come from 548 judged sessions with Claude Code, Codex, Cursor, Grok Build CLI and Muse Code, spread across 11 realistic codebases, with every session read by a judge.
What coding agents choose for usage-based billing
Across 548 judged sessions, Metronome was chosen most often, in 41% of runs. Orb was second with 16%. In 20% of runs the agent wrote the code itself and adopted no product at all.
| # | Product | Runs won | Share |
|---|---|---|---|
| 1 | Metronome | 225 | 41% |
| 2 | Built in-house (no product adopted) | 107 | 20% |
| 3 | Orb | 88 | 16% |
| 4 | Lago | 62 | 11% |
| 5 | Stripe Billing | 13 | 2% |
| 6 | CGRateS | 13 | 2% |
| 7 | OpenMeter | 9 | 2% |
| 8 | Oracle BRM | 7 | 1% |
| 9 | PortaBilling | 6 | 1% |
| 10 | Solvimon | 6 | 1% |
Full board, every run replayable: the usage-based billing leaderboard.
What the shape of this category means
The leader takes 41% of runs and there is a real second place. The category has a default but it is not settled.
Metronome at 41% with Orb at 16% is a default with a real challenger behind it. The agent is choosing rather than reaching, which means the inputs it uses can move the answer.
The work is to be the easiest correct answer: a quickstart that runs when pasted, documentation that states the current version, and pages that answer the exact configuration questions agents search for.
The agents do not agree with each other
In this category Claude Code, Codex and Cursor all put Metronome first, which is less common than it sounds: across the 31 categories we measured, Claude Code and Codex disagreed on the leader in 15 of them.
Grok Build CLI (26 sessions) and Muse Code (99 sessions) join this table with fewer runs, so read their rows as indicative.
| Agent | Runs | Picked most often |
|---|---|---|
| Claude Code | 127 | Metronome (46) |
| Codex | 164 | Metronome (81) |
| Cursor | 132 | Metronome (66) |
| Grok Build CLI | 26 | Metronome (16) |
| Muse Code | 99 | Metronome (16) |
Even where they agree, they get there differently. In this category Codex ran a web search in 100% of its sessions and Claude Code in 37%, so what you publish reaches nearly all of Codex's usage-based billing sessions and more than a third of Claude Code's.
Who is asking changes the answer
Every request was written as a specific kind of person. In this category Metronome led for every persona, which is a sign of a strong default.
| Who is asking | Runs | Picked most often |
|---|---|---|
| Junior developer | 100 | Metronome |
| Senior engineer | 202 | Metronome |
| Enterprise team | 246 | Metronome |
What you are really competing against
In 20% of runs, the agent wrote the code itself. That makes hand-written code the largest single competitor in this category, larger than most vendors in the table above.
This changes the job of your content. Before you argue that you are better than another vendor, you have to argue that the problem is harder than it looks. What breaks at volume. Which edge cases cost a weekend. What the maintenance actually costs after six months.
That argument has to exist as a page an agent can read, with specifics and numbers. "It is harder than you think" is not an argument. "Here are the four failure modes and what each one costs" is.
Considered, and never chosen
Because the judge records every product an agent raised and not only the one it picked, this board also shows who kept reaching the shortlist and losing. In usage-based billing the clearest case is Chargebee: on the table in 195 sessions, chosen in none.
| Product | Raised in | Chosen in |
|---|---|---|
| Chargebee | 195 sessions | 0 |
| Kill Bill | 118 sessions | 0 |
| Recurly | 100 sessions | 0 |
| Maxio | 44 sessions | 0 |
| Amdocs | 38 sessions | 0 |
Being rejected is a better position than being unknown, and a cheaper one to fix. The product is already in the agent's head and on the list. Whatever ended those 495 sessions is recorded in each transcript, one reason at a time.
What to do about it in usage-based billing
- Argue that the problem is harder than it looks, before you argue that you are better than a rival. 20% of usage-based billing sessions ended in hand-written code, so in roughly one session in 5 no vendor was in the running at all. Write the failure modes and the year-two maintenance cost, with numbers, in the documentation rather than the blog.
- Aim at second place first. Metronome holds 41% and Orb holds 16%. The gap between the default and the field is where the reachable sessions are.
The work that applies to every category rather than to this one is written up separately: audit your documentation, write a quickstart an agent can follow, and how to measure install share.
Every usage-based billing platform on this board
One page per product, with its install share, the per-agent split, and how often it was raised without being chosen.
- Do coding agents recommend Metronome? — chosen in 41% of sessions
- Do coding agents recommend Orb? — chosen in 16% of sessions
- Do coding agents recommend Lago? — chosen in 11% of sessions
- Do coding agents recommend Stripe Billing? — chosen in 2% of sessions
- Do coding agents recommend CGRateS? — chosen in 2% of sessions
- Do coding agents recommend OpenMeter? — chosen in 2% of sessions
- Do coding agents recommend Chargebee? — raised in 195 sessions, chosen in none
- Do coding agents recommend Kill Bill? — raised in 118 sessions, chosen in none
- Do coding agents recommend Recurly? — raised in 100 sessions, chosen in none
Where these numbers come from
548 judged sessions in usage-based billing across 11 codebases, part of a published set of 15,051. Real coding agents at pinned versions, in sandboxes, inside realistic codebases, with a simulated project owner in the loop and a blind judge on every session. The full method is on one page: how we measured this.
Every usage-based billing run can be replayed on the board.
<!-- generated by scripts/write-data-pages.mjs -->
Common questions
How many codebases is this based on?
548 judged sessions across 11 realistic codebases. A category only runs on repositories where its seam is open, so coverage differs: some categories ran on more than ten codebases and some on two.
What usage-based billing platform do coding agents choose?
Across 548 judged sessions, Metronome was chosen most often, in 41% of runs. Orb was second with 16%. Every agent put Metronome first.
Do Claude Code and Codex pick the same usage-based billing platform?
Yes. Claude Code and Codex both put Metronome first in this category, which is less common than it sounds: they disagree on the leader in 15 of the 31 categories we measured.
How often do agents build usage-based billing themselves instead of installing something?
In 20% of runs the agent wrote the code itself rather than adopting a product. That makes hand-written code one of the strongest competitors in the category.
How can a vendor improve its position here?
Make the quickstart run when pasted, state the current version on the documentation page, use one name across product, package and import, write pages for the symptoms users describe rather than only the category name, and get into the repository through templates and framework integrations.
Which usage-based billing platforms do agents consider but never choose?
Chargebee (raised in 195 sessions, chosen in none), Kill Bill (raised in 118 sessions, chosen in none), Recurly (raised in 100 sessions, chosen in none), Maxio (raised in 44 sessions, chosen in none), Amdocs (raised in 38 sessions, chosen in none). Being considered and not chosen is a different problem from being unknown, and it is usually fixable.
Where this comes from
Armature ran 15,051 judged sessions with Claude Code, Codex, Cursor, Grok Build CLI and Muse Code inside 92 realistic codebases, and published every run. The numbers on this page come from that work.