The AI Bill Grew Faster Than the Work. Here’s What We Changed.

How BitSafe Runs, Companion Essay

Our AI bill once grew faster than the amount of useful work we could point to.

The system was still running. Tasks completed. No dramatic outage announced that something was wrong. The problem appeared in the relationship between spend and work: more usage was reaching the bill without a matching rise in completed outcomes.

That made cost a reliability question.

A system can overspend because demand increased, but it can also overspend because the wrong model handled routine work, a schedule fired too often, retries repeated a bad instruction, or an agent kept calling tools without making progress. Those are operating failures expressed in money.

We changed the way we manage AI cost around one principle: every meaningful unit of spend should be attributable to work, and surprising spend should trigger investigation before it becomes a monthly explanation.

The controls are still incomplete. The practices are durable.

A total bill tells you what happened to the account. It does not tell you what happened inside the system.

Our early cost view was better at addition than diagnosis. We could see aggregate usage, but attribution across every execution surface was partial. That meant a growing total could not immediately answer the questions operators needed.

Which workflow spent the money? Which model handled it? How many attempts ran? Did the task complete? Did the result reach the intended record?

Without those links, optimization becomes guesswork. A team can lower a global limit or switch models broadly, but it cannot distinguish useful demand from waste.

We now treat task, workflow, model, and outcome as the core attribution chain. The implementation can vary by system. The requirement does not.

Attribution also needs a coverage statement. If some sessions or external services are missing from the ledger, the scorecard should say so. Partial telemetry can still guide decisions. It should not present itself as complete.

The strongest available model should not become the default for every request.

Routine retrieval, classification, formatting, and deterministic updates often need less reasoning than architecture review or a decision with material consequences. Sending both classes of work through the same expensive path raises cost without guaranteeing better output.

We moved toward explicit routing based on the job.

A cheap deterministic check should handle work that is already encoded as a rule. A smaller model can classify or format when the task has narrow boundaries. A stronger model belongs on work that needs deeper reasoning, broad synthesis, or careful judgment.

The important word is explicit. Each route should have a reason, an escape hatch, and a way to test whether quality held.

Routing based on vague prompt complexity can drift. New workflows may inherit the wrong default. A comment in code may describe the intended behavior while production logs show something else. We therefore review actual execution rather than trusting the design description.

The goal is not to force every task onto the cheapest model. It is to stop paying for capability the job does not use.

Retries are useful when a failure is transient. They are expensive when the instruction, permission, or source is wrong.

An uncapped retry loop can repeat the same failure while creating new work for operators. Fan-out creates a similar risk. Parallel agents can speed up research, but a broad dispatch without a stopping rule can multiply the cost of a poorly scoped question.

Every recurring or multi-step workflow should define a retry budget. The system can attempt a known safe recovery within that limit. After the limit, it should stop and surface the evidence.

Fan-out needs a budget as well. The task should state how many parallel branches are justified, what each branch contributes, and how the results will be consolidated. More agents do not automatically create more insight.

A bounded system makes failure visible. An unbounded one can hide the original issue under activity.

Runaway cost often looks like legitimate work at the level of one action.

A tool call may be permitted. A retry may be individually cheap. A scheduled check may finish successfully. The problem appears only when the pattern repeats without changing state.

This is why loop detection should measure progress, not just errors.

Useful signals include repeated calls to the same tool, many attempts against unchanged input, recurring runs that produce no new result, and rising spend without a corresponding completion event.

The response should be proportionate. A workflow can stop, reduce scope, or ask a person to clarify the goal. It should not keep spending simply because no single action crossed an alarm threshold.

This also changes the meaning of a cost spike. The first question becomes “what repeated?” rather than “which invoice line is largest?”

Language models are good at interpreting ambiguity. They are a costly way to perform work that a clear rule can already describe.

If a workflow only needs to compare a timestamp, validate a field, transform a known format, or query a structured source, deterministic code is often the better component. It is easier to test and cheaper to run. It also produces a clearer failure mode.

The model should enter where judgment begins. It can interpret an unusual exception, synthesize evidence, or propose the next action. It does not need to sit inside every mechanical step.

This separation improves reliability as much as cost. Deterministic execution reduces variation. The model can spend its reasoning budget on the part of the workflow that benefits from it.

One account-level cap is necessary and insufficient.

A useful control system watches several horizons. A task can have a per-run limit. A workflow can have a retry or daily budget. The broader system can track pacing across the month. Alerts can trigger when usage changes faster than expected.

The exact thresholds are internal operating details. The design principle is public: controls should stop a local mistake before the organization-level limit becomes the first line of defense.

Alerts also need context. “Spend is high” is not a decision-shaped message. A better alert identifies the workflow, recent change, number of attempts, model route, and whether useful work completed.

That context lets an operator choose among the real options: allow the demand, change the route, pause the workflow, fix the instruction, or retire the component.

Custom systems create costs that do not appear on a model invoice.

Maintenance, monitoring, security review, and operator time all belong in the decision. A packaged feature may become cheaper or more capable than an internal component even when the internal code still works.

BitSafe runs a recurring build-versus-buy review for this reason. We compare current vendor capabilities with the parts of NanoClaw we maintain. The output is not a pledge to buy or to build. It is a prompt to revisit assumptions.

Reversibility matters. A narrow component with a clear interface is easier to replace. A system that treats every internal feature as part of its identity will keep paying maintenance costs after the original reason has disappeared.

Cost discipline includes deleting work that no longer earns its place.

A surprising bill is evidence.

It can reveal a routing default that no longer matches the workload. It can expose a schedule that changed quietly, a retry path that lost its limit, or a monitor that never learned to detect silence. It can show that context grew while output stayed flat.

The response should begin with diagnosis, not indiscriminate cuts.

Ask what changed in work completed, execution volume, model mix, retries, context size, and schedule frequency. Compare spend with outcomes at the same level of detail. Fix the largest structural issue first, then watch whether quality and completion held.

We do not claim that our cost controls are finished. Attribution still has gaps, and new workflows create new failure modes. The durable improvement is the operating loop: attribute, route, bound, detect, review.

That loop turns cost from a finance surprise into an early warning system.

AI cost is not only a pricing problem. It is a measure of how the system behaves when nobody is watching each step.

Attribute spend to work. Match model capability to task needs. Cap retries and fan-out. Stop loops that make no progress. Use deterministic execution for predictable steps. Set controls before the organization-level ceiling. Revisit whether custom components should still exist.

Then investigate any cost increase that arrives without a clear increase in useful work.

The bill will never explain the whole system. Read properly, it can tell you where to look.

Subscribe to the BitSafe newsletter for more practical notes on running AI systems.