Observability tells you what you spent. It can't tell you how to spend less.

If you have gone looking for a way to control AI spend, you have met the category: Helicone, LangSmith, Langfuse, Portkey, LiteLLM, and the FinOps platforms that roll AI tokens into a cloud-cost dashboard. They are good tools. We built importers for two of them.

They all share one shape. They instrument the runtime, watch requests go by, and report what was spent. That is observability, and it answers exactly one question: what did I spend? It is silent on the two that follow — how do I spend less? and did the change I made actually save money without breaking anything?

The category admitted the gap

You do not have to take our word for it. In a 2026 review of AI cost-optimization tooling, the FinOps vendor Amnic surveyed the field — gateways, observability platforms, cloud-spend managers — and concluded:

"No tool performs static code analysis or pre-deployment LLM cost prediction … a meaningful blind spot for preventing costs rather than just tracking them."

That is a competitor describing the empty shelf. Every tool they list sits at runtime, after the code is written and deployed. None reads the source to find the waste before it ships, and none generates the fix.

Why runtime is the wrong place to fix a code problem

The waste is decided in code. A wrong-model default, an uncached system prompt, a document passed whole when a paragraph would do, a call fired twice in a loop — these are lines in a repository. By the time they show up on an observability dashboard, three things are already true:

The money is spent. Observability is a rear-view mirror; the bill already arrived.
The pattern is embedded. It is not one bad request — it is a decision baked into a code path that runs thousands of times a day.
Nobody knows which line to change. A dashboard shows a number going up. It does not hand you the diff.

Runtime tools are strong at attribution — this feature, this customer, this model cost this much. That is real value. But attribution is not remediation. Knowing that your chatbot costs $8,000/month is not the same as knowing that one timestamp in a system prompt is quietly forfeiting your prompt-cache discount across every call.

The cost-verification layer

erabot sits one layer earlier, at the code. It does three things observability structurally cannot:

Detect at the source. It parses your code, finds every LLM call site — including the framework-wrapped ones a regex misses — and identifies the caching, model, context, and dedup waste before it ships.
Generate the fix. Not a chart. A diff, with the cost arithmetic behind it.
Verify the fix is safe. For any change that could affect output — like swapping to a cheaper model — it replays real inputs through old and new, judges the quality, and only recommends the swap if quality holds. (More on that harness in a separate post.)

And it does this without your code leaving your environment: erabot audit runs the whole engine on your own infrastructure with your own model keys.

This is not a knock on observability

Keep your observability stack. You need to know what you spent, per feature and per customer, and the runtime tools do that well. erabot is the layer they don't have — the one that reads the code, writes the fix, and proves it saved money without costing you quality.

Observability tells you the bill went up. erabot tells you which line to change, and what it will save.

Observability tells you what you spent. It can't tell you how to spend less.

The category admitted the gap

"No tool performs static code analysis or pre-deployment LLM cost prediction … a meaningful blind spot for preventing costs rather than just tracking them."

Why runtime is the wrong place to fix a code problem

The money is spent. Observability is a rear-view mirror; the bill already arrived.

The pattern is embedded. It is not one bad request — it is a decision baked into a code path that runs thousands of times a day.

Nobody knows which line to change. A dashboard shows a number going up. It does not hand you the diff.

The cost-verification layer

erabot sits one layer earlier, at the code. It does three things observability structurally cannot:

Detect at the source. It parses your code, finds every LLM call site — including the framework-wrapped ones a regex misses — and identifies the caching, model, context, and dedup waste before it ships.

Generate the fix. Not a chart. A diff, with the cost arithmetic behind it.

Verify the fix is safe. For any change that could affect output — like swapping to a cheaper model — it replays real inputs through old and new, judges the quality, and only recommends the swap if quality holds. (More on that harness in a separate post.)

And it does this without your code leaving your environment: erabot audit runs the whole engine on your own infrastructure with your own model keys.

This is not a knock on observability

Observability tells you the bill went up. erabot tells you which line to change, and what it will save.