Why AI coding agents burn through API credits so fast

Ask an AI coding agent to fix a bug and it doesn't send one request. It reads the file, greps for related code, runs the test, reads the failure, edits, reruns, and reports back — each of those is its own call to the model, and most of them carry the same growing context window along with them.

A chat interface is one human, one message at a time, with an obvious cost intuition: you can feel a long conversation getting expensive. An agent loop has no such feedback. It runs at machine speed, in a tool-call cycle a person never directly reads, and the first time the cost becomes visible is the invoice.

Where the money actually goes

• Repeated context — the same file, the same instructions, resent on every tool call in the loop
• Exploration — grep, list, read, read again, before a single edit happens
• Retries — a flaky test or a bad edit triggers another full loop, not just another line
• Model tier — using a frontier model for work a smaller one would do just as well

None of these are bugs in the agent. They're the correct behavior for the job — write, verify, adjust. The waste isn't in any single call, it's in doing all of that on the most expensive model available, every time, with nothing checking whether a cheaper path would have worked.

The fixes are boring, on purpose

Prompt caching handles the repeated-context part automatically on the provider side for a lot of workloads, and it should be the first thing you check is actually landing — a surprising share of "agent cost" complaints turn out to be a caching misconfiguration, not a model-choice problem.

The rest is routing and limits: send the exploratory work — reading files, summarizing, short completions — to a model you already run locally, keep the frontier model for the parts that actually need it, and put a hard number on what a run is allowed to spend before it can go past you unattended.

The tooling to catch a runaway agent run usually exists somewhere. It just isn't in the path where the request actually happens.

Why the dashboard finds out last

Provider dashboards aggregate. They tell you that yesterday cost $340, not that one agent stuck in a retry loop between 2am and 6am accounted for $280 of it. By the time the number is visible it is describing money already spent, and the granularity is wrong for the question you actually have, which is which process on which machine did this.

That is the gap that makes agent spend feel uncontrollable rather than merely expensive. A cost you can attribute is a cost you can fix. A cost that arrives as one monthly total is just weather.

A short checklist before you change anything

• Confirm prompt caching is actually landing — check cached vs uncached input tokens on real traffic, not on a toy request
• Find your most expensive single run, not your most expensive day; the tail is usually one loop, not general usage
• Check what fraction of calls are pure exploration (read, grep, list) and could have gone to a smaller model
• Put a number on what a single run is allowed to cost, before you need one

Where Probe0 fits

Probe0 sits between your agent CLIs and the model providers as a local proxy, so it sees every one of those small calls instead of one big invoice at the end of the month. It routes the cheap work to a model you already run in Ollama or LM Studio and retries weak answers upstream, answers repeat calls from a local cache, collapses simultaneous identical calls into one, and pauses a run before it clears a number you set.

The part that matters most for the attribution problem is the ledger: model, tokens, real cost, latency, and which process made each call, written to your own disk. That turns "last month was expensive" into "this agent, in this run, at this hour" — which is the version of the question you can actually do something about.