--- title: "Forecast the Work, Not the Token Price" description: "Forecast AI coding costs by work class, attempts and proof, then update the route when actual cost or acceptance moves outside the plan." author: "Gunner Technology" published: "2026-11-09" url: "https://www.gunnertech.com/blog/forecast-agent-costs-by-work-class" --- # Forecast the Work, Not the Token Price Forecast AI coding agent costs by estimating attempts, context, proof and recovery for each class of work. Don't multiply a token price by a headcount guess. The bill follows what the factory tries to finish, not how many people have access to a chat box. ## What should an AI cost forecast measure? An AI cost forecast should measure a repeatable class of work from intake through acceptance. A work class is a group of jobs that need roughly the same context, checks, authority and recovery path. A copy change, a dependency update and a payment migration are three different classes even when the same agent can attempt all of them. For each class, estimate the number of jobs, the attempts each job usually needs and the machinery that surrounds an attempt. Include repository search, retrieved context, model calls, build runners, reviewers, security checks and the likely return trips after a failure. The model call is only one station on that route. Keep the forecast beside the work, not inside a finance spreadsheet that the factory never sees. Give each job a durable identifier and carry it through every attempt. That is the bridge between the plan and the actual bill, and it is why [agent costs belong to accepted work](https://www.gunnertech.com/blog/allocate-agent-costs-to-accepted-work) rather than seats. ## How do failed attempts change the forecast? Failed attempts stay in the forecast because the factory paid for them. If a class of work usually needs a repair pass, budget the repair pass. Planning as though every first attempt will pass does not make the factory efficient; it makes the next variance report inevitable. Separate an ordinary retry from recovery. A retry repeats a bounded attempt after a known failure. Recovery may need a person to investigate, restore state, change the specification or choose a different route. Those events have different costs and different fixes, so one average retry multiplier hides the decision you need to make. Use a range when the history is thin. Name the assumptions: expected job volume, likely attempts, proof route and escalation rate. A range with visible assumptions is a forecast someone can challenge. A precise total built on imaginary first-pass success is decoration. ## Where do model prices belong in the plan? Model prices belong in the conversion layer, after the work and usage units are defined. Preserve requests, input, output, cached usage and any other billable units the route exposes. Apply the current rate to those units, but do not erase the units when a vendor changes the price. That separation lets you rerun the plan without pretending the workload changed. A price cut may lower the expected bill for one route. It does not prove that the cheaper model will need the same number of attempts or pass the same checks. [The price card is not the bill](https://www.gunnertech.com/blog/the-price-card-is-not-the-bill) because routing, context, verification and recovery still decide the complete cost. Forecast fallback routes too. If restricted work must stop when its approved model is unavailable, the forecast needs the cost of waiting. If another model may take over, price its likely usage and its proof route. A fallback that exists only in an architecture diagram is not capacity you can plan around. ## What should happen when actual cost misses the forecast? A miss should change the route, the estimate or the work itself. Compare forecast and actual cost at the work-class level, then ask which assumption moved: volume, attempts, context, model rate, verification or recovery. A total account overrun cannot tell the factory what to do next. Do not punish a team for exposing failed work. A route that reports every rejected attempt can look worse than one that loses the link between usage and outcomes. Reconcile the identifiers first. Then decide whether the class needs tighter intake, less context, a different model, stronger proof earlier or a faster stop for human judgment. Give every budget a mechanical response. A warning can slow admission of low-consequence work. A hard boundary can stop new attempts while work already in a safe state waits. The broader rule is that [the budget is part of the harness](https://www.gunnertech.com/blog/the-budget-is-part-of-the-harness): it must govern what happens next, not merely explain last month's invoice. ## How do you build the first useful forecast? Choose one recurring class of work with a clear acceptance decision. Pull a small run of completed jobs, including the rejected ones. Record their attempts, usage units, check costs and interventions. Use that evidence to set a range for the next run and write down every assumption. Review the range when the run ends. Do not wait for a quarterly budgeting ritual. If actual work repeatedly lands outside it, split the class or change the route. A category called engineering work is too broad to forecast; a category called routine dependency updates with the standard security and browser checks can improve with every batch. Gunner Technology's position is simple: cost forecasting belongs on the factory floor. Finance should see the expected bill, but the agents and gates need the budget while they can still change the outcome. Forecast the work, watch what survives, and make the next route earn its capacity. ## Quick answers ### Can we forecast costs before we have much history? Yes. Start with a range and list the assumptions behind it, then replace guesses with measured attempts and acceptance results after each run. ### Should every team receive its own agent budget? Only when the team controls the work and route that spend belongs to. Shared factory costs still need one visible allocation rule. ### Does a lower model price reduce the forecast automatically? It reduces the rate applied to the same usage. Reforecast the complete route if the cheaper model changes attempts, context, proof or recovery.