Capping a Coding Agent: Per-Run Budgets, Fallback, Attribution

What it does

A gateway is what lets you give a coding agent autonomy without giving it an uncapped card. Scope a key per agent or per run, put a budget and a rate limit on it, and the worst case stops being "it looped overnight and we found out on the invoice" and becomes "it hit its ceiling and paged someone."

A coding agent is the most demanding LLM workload most teams will ever run. One task fans out into plan, edit, run the tests, read the failure, edit again — hundreds of calls, often concurrent across sub-agents and tools, running for minutes at a time. The autonomy is the value. It is also the risk: a loop with a bug does not make one bad call, it makes a thousand, and it makes them faster than a human can notice.

This post is about the controls a customer actually turns on, what one real agent run costs when you write it out, and where the controls stop.

The job it does for you

The workflow before. The agent holds a provider key with the same scope as everything else in the organisation. There is no ceiling, because the provider bills the org rather than the job. Cost per task is unknown, so nobody can say whether the agent is cheaper than the engineer it is helping. A provider blip mid-task strands a half-applied change and somebody cleans it up by hand. When someone finally asks "what did the agent cost last month," the answer is a slice of a number nobody can slice.

The workflow after. Each agent — and, if the runs are expensive enough, each run — gets its own key. On that key: a budget, a rate limit, and a model allowlist. A looping run stops at its own ceiling and leaves the other agents untouched. Each call is tagged with the agent, the task and the step, so "what did this run cost" is a sum over rows rather than a reconstruction. A provider blip reroutes rather than strands. Revoking one misbehaving agent revokes exactly one agent.

The gap between those two lists is not a feature you write once. It is budgets, rate limits, fallback chains and attribution tags — four builds, each of which lands on the backlog after the incident that demanded it.

Why coding agents stress a gateway harder than chat

Chat traffic is bursty in a predictable way: one human, one request, a bounded number of tokens, a person watching the screen. An agent loop breaks all four assumptions.

The concurrency row is also where the upstream limits bite: OpenAI and Anthropic both publish per-model request- and token-per-minute ceilings (OpenAI rate limits, Anthropic rate limits), and a sub-agent fan-out is the workload most likely to find them. The fourth row is the one that catches finance and the fifth is the one that catches engineering. Both are contained by the same mechanism, which is that every call passes through one place that can say no.

How it works

What you configure. A virtual key scoped to one team, carrying a budget ceiling, RPM and TPM limits, and the set of models it may reach. For agents, the useful granularity is one key per agent, and one key per run when a single run can cost more than you would happily lose. The org/team/key scoping model is org, team, member.

What happens to a call. The key resolves to an organisation and a team. Guardrails run pre-call. Every ceiling is checked before the provider is called — a check that happens afterwards is a bill you already incurred. Credit is held against the call, the provider is called, post-call guardrails run on the way back, and then the hold is settled against the real cost.

That hold is why the ceiling survives an agent. Fifty concurrent sub-agent calls against a $20 budget cannot each read "$18 spent, fine" and all proceed: the credit is reserved before the provider call and settled after, so the burst cannot slip past. The mechanism is reserve-and-settle, and it is the difference between a ceiling and a suggestion.

What comes back when the ceiling bites. A specific error, not a generic one:

Both are ordinary HTTP — 429 is RFC 6585 §4, 402 is RFC 9110 §15.5.3 — which matters because an agent runtime's generic retry policy will usually already back off on 429 and has no rule at all for 402. An agent loop should treat both as terminal for the run rather than as something to retry through. The client-side handling is handling 429 and 402, and choosing between the two control types is budgets vs rate limits.

Set it up

1. Create a key per agent, not per organisation. From the dashboard, one key scoped to the team that owns the agent. The full sk-nrouter-… is shown once; store it where the agent runtime reads its secrets. Lifecycle is in API key management.
2. Set the budget before the first run, not after the first surprise, in budget controls. Pick a number you would be willing to lose to a bug, because that is exactly what the number is for.
3. Set an RPM limit too. A budget bounds the money; a rate limit bounds the blast radius in time, which is what stops a runaway loop from spending its whole ceiling in ninety seconds.
4. Restrict the model allowlist to the models the agent should be reaching. An agent that can only call two models cannot accidentally discover an expensive third.
5. Tag every call with the agent, the task and the step.
6. Point the runtime at the gateway — two strings.

- client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
+ client = OpenAI(
+     base_url="https://api.nrouter.ai/v1",
+     api_key=os.environ["NROUTER_API_KEY"],
+ )

resp = client.chat.completions.create(
    model="claude-sonnet-4-5-20250929",
    messages=messages,
    extra_body={
        "metadata": {
            "tags": [f"agent:coder", f"task:{task_id}", f"step:{step}"],
        }
    },
)

Worked example with numbers

A platform team runs a code-fixing agent over a backlog: 400 task runs a month, averaging 180 model calls per run. Steps are not equal, so the interesting arithmetic is per step type rather than per run.

At 400 runs that is roughly $592/month — and the table is only possible because each call was tagged with its step. The two decisions it unlocks are both concrete. First, the per-run ceiling: a normal run costs $1.48, a stuck one costs many times that, so a $10 per-run budget is generous for the good case and hard-stops the bad one. Four hundred runs at a $10 ceiling bounds the worst month at $4,000 rather than at whatever the loop could reach. Second, the routing: flagship calls are 40 of 180 calls but $1.20 of $1.48 — 81% of the cost on 22% of the calls. That is where the next section points.

The rates in that table are illustrative placeholders for the shape of the arithmetic; substitute the real per-token rates for the models you use from the models page and the provider pricing pages in ## Sources. Once traffic is flowing, cost vs usage does the same breakdown from measured data instead of assumptions, and multi-agent cost tracking covers the case where several agents contribute to one task.

Route steps by difficulty

The table above is the argument for per-step routing in one line: most agent calls are mechanical. Reading a file, formatting a diff, classifying a test failure, deciding whether output matches a pattern — those rarely need the flagship. Planning and writing the edit usually do.

Because routing is a gateway decision rather than agent code, you can move the cheap steps to a cheaper model and watch the success rate rather than rewriting the loop:

1. Tag every call with its step, as above.
2. Read the per-step cost breakdown for a week of real runs.
3. Pick the highest-volume mechanical step and route it to a cheaper qualifying model — the framework is route by cost vs quality.
4. A/B test the change against task success rate, not against a benchmark, because the only metric that matters is whether the run still finishes.
5. Keep the change if success holds; revert it if it does not. Neither branch touches the agent.

In the worked example, moving the 140 cheap calls to a model half the price saves $0.14 a run — small — while moving even a third of the flagship calls saves ten times that. The measurement is what tells you which, and the measurement is what a gateway gives you.

What it costs

From the pricing page:

• Pay as you go — $0 subscription, 4% platform fee added on top, measured as 4% of your credits. On the $592/month agent above, the credits cost $615.68, so the fee is $23.68/month.
• Pro — $50/mo or $500/yr, 0% platform fee.
• Enterprise — custom, 0% fee, contact sales only.

At $592/month of agent spend, pay as you go is the cheaper plan and we would rather you stayed on it: the crossover is where the fee on your monthly spend (4% of spend) passes the subscription, around $1,250/month monthly and around $1,042/month annual. An agent fleet crosses that line quickly once it is doing real work, and the walkthrough for when to move is from credits to Pro.

Every control in this post — budgets, rate limits, fallback, tagging, A/B tests, guardrails — is on every plan. Plans vary the fee and the rate limits, nothing else; the reasoning is we charge a fee, not a gate. Signup is not free: a card is required and a real $5 minimum charge is taken, with the fee on top.

Where it fits with the rest of the platform

• Agentic workflows generally. The same controls beyond the coding case. nRouter for agentic workflows.
• Routing for agent pipelines. How the routing decision is made when a pipeline has several model-shaped stages. LLM routing for AI agent pipelines.
• Guardrails. An agent that can call tools is an agent that can be prompt-injected — the class the OWASP Top 10 for LLM Applications puts first, and one that reaches an agent through file contents and test output, not only through the user's message. Guardrails run pre-call and post-call on every request. Guardrails on every request.
• Per-customer billing. If your agent serves customers, the per-run cost above is the billing input. Per-customer LLM billing.
• Reading the ledger. Reconciling agent spend against your balance. How to read your LLM credit ledger.

Limits and what it will not do

• Fallback does not make a retry free. This is the correction most worth making: a retried call is a second call to a provider and therefore a second charge for the attempts that were served. The general shape of the problem — retries amplifying load rather than absorbing it — is the AWS Builders' Library piece on timeouts, retries and backoff with jitter; the billing consequence is the part that is specific to LLM traffic. What the gateway guarantees is that the credit hold is taken once per customer request rather than once per attempt — not that failover is free. Provider fallback chains works through why a naive failover double-charges.
• A budget stops calls; it does not roll back work. When a run hits its ceiling mid-edit, the edits already applied stay applied. Your agent needs a checkpoint or an undo path of its own; the gateway can only stop spending.
• A ceiling is not a correctness check. An agent that loops productively and expensively is indistinguishable from one that loops uselessly, as far as a budget is concerned.
• An unpriceable call is reported, not guessed. x-nr-request-cost is absent when the cost cannot be determined, paired with x-nr-cost-status: unpriced. Never read a missing header as zero — the argument is cost honesty.
• No BYOK. You cannot bring a provider key; nRouter holds the provider relationship. Why we do not do BYOK.
• Bodies are not logged or retained for you. Agent prompts contain source code, and none of it reaches the audit trail, which is metadata only. One qualification: a response body may sit for a few minutes in a short-lived serving cache, keyed to your organisation and team, so a byte-identical repeat call skips the provider — a cache you cannot read back and not a record of anything. If you want prompts retained, forward them to a sink you control and read what to log and not log first.
• SOC 2 Type II is in progress, not certified. Posture is on the trust page.

Try it

Create an account at signup and load the $5 minimum, with the platform fee on top. Then do the smallest useful version of this post: create one key for one agent, put a budget on it that you would be willing to lose, tag every call with the step, and let the agent work through ten real tasks. You will have a per-step cost table like the one above built from your own traffic, and a defensible number for the per-run ceiling. Deliberately set the budget to a dollar first and watch the 429 key_budget_exceeded arrive — a ceiling you have never seen fire is a ceiling you have not tested.

See also

• nRouter for agentic workflows — the same controls generalised past coding agents to any autonomous loop.
• Virtual keys vs master key — how to scope the per-agent key so a bad run cannot become everyone's incident.
• Reserve-and-settle: never overspend a credit balance — why the ceiling holds when fifty sub-agent calls arrive at once.
• Multi-agent cost tracking — attribution when several agents contribute to one task.
• Cost-vs-Quality LLM Routing: Which Tasks Can Go Cheap — the decision framework behind the per-step routing section.
• Handling 429 and 402 errors from an LLM gateway — what the agent runtime should do when a ceiling fires.
• Models — the live catalog to substitute for the illustrative rates in the worked example.

Sources

Verified 2026-08-23. If a linked page has changed since, email hello@nrouter.ai and we will correct this post.

• nRouter plans and fees: nrouter.ai/pricing — $0 subscription with a fee on top equal to 4% of your credits, Pro at $50/mo or $500/yr at 0%, $5 minimum purchase.
• nRouter live model catalog: nrouter.ai/models — the models an agent key can reach today.
• Anthropic pricing: anthropic.com/pricing — per-model rates to substitute into the worked example.
• OpenAI API pricing: openai.com/api/pricing — per-model rates to substitute into the worked example.
• AWS Bedrock pricing: aws.amazon.com/bedrock/pricing — Bedrock is live on nRouter and AWS publishes its own rates.
• OpenAI API reference: platform.openai.com/docs/api-reference — the Chat Completions contract the examples above use.
• Provider rate limits: OpenAI and Anthropic — the upstream ceilings a fan-out hits before your own.
• RFC 6585 §4 (429) and RFC 9110 §15.5.3 (402) — the standard meanings of the two ceiling responses: datatracker.ietf.org/rfc6585, datatracker.ietf.org/rfc9110.
• AWS Builders' Library — timeouts, retries and backoff with jitter: aws.amazon.com/builders-library — why a retry policy is a load decision, not only a reliability one.
• OWASP Top 10 for LLM Applications: owasp.org — the injection classes a tool-using agent is exposed to.

Anthropic, OpenAI and AWS are trademarks of their respective owners. nRouter is not affiliated with or endorsed by them. The per-call rates in the worked example are illustrative placeholders and are labelled as such; substitute the live rates from the pages above.