AI agent cost management fails when cost is treated as a monthly bill as opposed to a runtime signal.

A coding agent spends money differently than a bill. The agent could spend money by selecting a model for a specific task, using dragged-in context from past tasks, calling tools along the way from past tasks as well as other subagents that are passed work to complete. And the spending happens in a loop of retry and re-evaluation and passing of work until a harness or developer stops the agent from running more.

First, LangChain concisely outlined the problem with spend from coding agents in its June 15 post about making coding-agent spend predictable: a heavy user can spend thousands per week before anyone notices. Anthropic's 2026 coding-agent report gives the other side of the same pressure. Developers already use AI in roughly 60% of their work while fully delegating only 0 to 20% of tasks. So even if the behavior of an agent could be made predictable and therefore controllable, the agents are already active enough that they consume tokens, pay for tools, and pay for reviewer time.

The bill arrives after the behavior

The spend is treated as finance information and finance sees the spend after the system has already behaved. Engineering owns the behavior of the coding agent.

A normal cloud bill has a simple shape. One can attribute the cost to a service, environment, team, or cluster. The spend of coding agents has a different shape. An expensive coding agent can have a simple spend behavior, for example a retry policy, a growing context window over the lifetime of a task, or a fallback policy that promotes a cheap model call to an expensive reasoning model. The cost of a coding agent is heavily influenced by the tool loops that it executes, especially search that stops only when a confidence threshold is reached.

Orq defined an AI agent FinOps framing that points at the right unit. Agent costs are determined by runtime behavior. When finance and agents come together, the useful metric is cost per outcome rather than cost per token. A five dollar workflow that produced the correct fix for a support case can be cost efficient compared to a fifty cent workflow that opened trace after trace of garbage work for a human to resolve.

The monthly invoice cannot tell the difference.

This is why the cost conversation has to happen next to traces, evals, owner fields, and policy changes. We have been making this point for months, just in different words: traces have to become operational evidence, not mere exhaust. Cost is another field in that evidence.

Cost control works when spend, traces, outcomes, and harness policy sit in one loop.

Caps are crude without traces

This same approach shows up in LangChain's internal rollout of cost control to coding agent usage, using LangSmith LLM Gateway budgets scoped by organization, workspace, user, and API key. That system includes monthly, weekly, daily, and hourly budgets, with allowances for users and projects in special circumstances to spend more than a default window allows. Treat those as production controls, not account codes.

The same simple monthly budget can be killed by one expensive task while the rest of the month looks fine. That same hourly limit that stops the expensive task in its tracks can cut into a long-running cheap task that is producing value. A cap only helps when the team has a good sense of the cost's runtime path.

The good question here is mundane and hard to pull off: which trace went over budget; what model route did it use; who or what workflow triggered it; which tool calls were involved; what retry or eval loop drove up the cost; and was the outcome worth the burn?

Similarly, tracing the harness or agent for a single run is the same information required to debug a pipeline rather than a single prompt. A prompt trace alone will not expose enough information to diagnose the run. The trace of the harness shows whether the agent cost more because it was doing hard work, stuck in a failure-and-retry loop, or carrying junk in the context backpack.

Budget windows should expose the loop

Agent cost controls fail when they are simply yes or no.

Instead of simply approving or denying cost, the budget window has to do a real job. It warns early; attributes the trace that is blowing through the money; throttles expensive loops with no end; permits named exceptions; and preserves enough detail for the next time the harness sees the same shape.

The budget window should expose the loop before the invoice does.

A coding-agent workflow can include searching for code in the repository, writing and running tests, setting up packages, opening a browser, and asking a stronger model for more reasoning around a failure. Once agents and models get integrated into developer work, the cost of running that agent starts to matter alongside the developer's time.

Finout's 2026 spending analysis shows volatility in individual inference calls. A single call can vary by model choice, context length, and agentic workflow shape. Small changes in routing or context can create large changes in cost with little change in the feature being built. Aggregate spend hides the actual path.

The path is the product.

The harness owns the budget

Spend ownership lands in the harness.

The harness determines the model route to be used for the agent. The harness determines the retries for the agent. The harness determines if the context retrieved from storage should be trimmed, summarized, retrieved in full, or left untouched for future retrieval. The harness determines if subagents should be spawned to perform subtasks. The harness determines which tools the agent may use to complete a task. The harness determines what to do with the failing eval: retry, escalate, open a ticket, or stop.

That is why cost policy belongs in the harness around the model. A proxy that sits alone is too thin. It can only say yes or no.

There is a large variance between a cheap model and an expensive model. A cheap model can end up being far more expensive due to the way it is used to complete tasks, namely looping on the same task. Conversely, an expensive model can end up being cost effective because it completes tasks quickly and does not have to be called again. Retrieval steps work the same way. They may save money by reducing context, or they may waste money by including irrelevant information. Tools can eliminate token churn, or they can create retry storms because the API contract for the tool is mushy.

Cost policy has to understand the architecture of cost. Let incident work cost more for customers. Stop refactoring work that costs too much after an hourly window crosses a threshold. Use stronger models only after cheaper models fail in specific ways. Stop retrying, even if retry is configured, after the same error in the same trace occurs three times. File an issue if the same workflow suddenly and repeatedly costs more over time.

This does not belong in a spreadsheet. Put it in the harness. The harness already controls model selection and usage for the agent workflow.

Cost per outcome is the only number that travels

Token counts are useful until they become a proxy for value.

Reducing tokens is a good thing right until the cheaper answer is still a bad answer. Caching prompts, trimming context, selecting a different model, or reducing evals all decrease token counts, but the work still has to execute successfully.

And for cost per outcome: for each outcome the customer wants, how much did the system have to spend to produce it? Cost per merged PR, cost per resolved ticket, cost per validated migration, cost per successful workflow, cost per human escalation avoided. Those are easier to take into a budget conversation than a pile of token counts. A lower token number says the team reduced tokens. Fine. The answer still has to work.

Honeycomb's stance on OpenTelemetry for AI makes sense because it highlights a real market tension. Richer dimensions of observation are required to understand how AI and agentic systems work: inference, prompts, tokens, RAG context, and request behavior. The platform cost conversation wants to reduce all of that to a single number. A team cutting the wrong field to hit a spend number removes the evidence required to spend money in a way that drives value.

The LangSmith documents around trace routing take a good stance here. Traces can be routed in LangSmith, OpenTelemetry, or both with runtime trace destination controls. The trace and its spend data should travel with the work through systems for reliability, review, security, and finance.

Cost is an attribute on the work.

Expensive traces should become owned work

The owner looks at the work that crossed the budget window and follows it through. The alert carried the trace, user, team, workflow, model route, tooling, retries, evals, outcome, and cost. The owner can decide whether the work was worth it and relax the cost policy for similar work in the future. If it was waste, alter the harness to prevent it.

This work is the same as turning recurring agent failures into owned issues. An expensive trace carries a bug report with a dollar sign attached to it.

Evaluation steers the harness by connecting cost, behavior, and outcome. Evaluations that detect repeated low-confidence tool use can function as cost control. A regression suite that proves a cheaper model still fulfills the task is cost control already. A trace query that shows a customer workflow accounting for a large part of spend is a product signal already.

The best cost work looks suspiciously like reliability work. Same owners. Same traces. Same release discipline. Same boring meetings where somebody has to explain why the graph did what it did.

Good.

Treat the invoice as a postmortem artifact

The invoice is useful, and late.

Agent spend is incurred in runtime decisions: where work flows, how context is aggregated, which retries are attempted, which tools or models are called, which model gets escalated. By the time finance sees the money spent, the relevant engineering question has already been asked and answered by the runtime.

AI cost optimization sounds like something to purchase from procurement until the cost work is wired into the runtime of the agents within the platform harness. The useful cost work looks suspiciously identical to reliability work: same owners, same traces, same release frequency. Yes, the same boring meetings where someone tries to explain why the graph behaved the way it did.

Put cost where the agent spends it.