AI cost, budgets and estimates

Every AI call Vera makes is recorded with its tokens, its model, and what it cost. This page is about reading those numbers and bounding them.

Before you spend: the estimate

The plan screen shows an estimated range for the batch you are about to generate, drawn from your own measured calls for that feature on that project — not from a price list and a guess at token counts.

It is a range with a sample size, because "≈$0.30 from 2 calls" and "≈$0.30 from 400 calls" are different statements. With too little history it says so instead of showing a number: a figure computed from list prices would look exactly like a measured one and would never be questioned.

It is scoped to the project because prompt size is a property of your app — a twelve-element landing page and a three-hundred-element admin console cost different amounts through the same feature.

While you spend: the budget

A generation job carries a budget — calls, tokens, cost, elapsed time. It is a runaway guard, not a quota: it exists so a job that starts looping cannot spend without bound, and a normal batch should never reach it. A budget that fires on ordinary work just teaches people to raise it.

If a job does stop at its budget, it returns what it produced plus the reason. Everything generated so far is real and already saved. A stopped job must never present as "the AI found nothing" — that would be a claim about your app rather than a fact about the budget.

Reading the numbers: null is not zero

This is the one thing worth internalising.

A failed provider call reports no usage at all. Its tokens and its cost are unknowable, not zero. So on every figure Vera shows you:

• the call count is exact;
• the token and cost totals are a floor;
• a flag says which, and how many calls could not contribute.

A dashboard that renders a floor as a total invites capacity decisions from a number that is quietly wrong in a direction nobody can see. Wherever you see a spend, look for whether it is marked exact.

Where to look

• Org settings → AI cost — your organisation's spend by feature, model and day.
• /admin → AI cost — the same, across every tenant (platform admins).

Which model runs what

Calls are routed by what they are being asked to do, since that is the only thing that predicts whether a stronger model earns its price:

• Transcription and classification run cheap. The answer is already in the input and the job is to restate it in a schema; a stronger model restates it identically.
• Grounded generation — steps for a page whose elements are listed, a repair for a failure whose DOM is attached — runs standard.
• Planning stays on the standard tier deliberately. Deciding which tests are worth having is the most open-ended thing Vera asks of a model, and it is where a bad answer costs the most: a weak plan wastes every generation call that follows it. Saving on the plan is the one saving that does not save anything.

You can pin a specific model per feature for your org; that always wins.

Truncation is always named

Any cap that actually affected a result is reported with the result: pages the extractor did not examine, rules ranked out of a prompt, source files a discovery did not read, chunks it did not analyse.

A silent cap reads as a complete answer. If a page has three hundred controls and the prompt showed sixty, a plan built from it is a different artifact from one built from the whole page — and only one of them can claim to have considered your app.

Two limiters, independently

If your organisation is using the free onboarding grant, that limit counts invocations and decides whether a call may happen at all. A job budget counts what happens inside one job. They do not know about each other, and both are honoured: exhausting the grant still takes you to the bring-your-own-key prompt exactly as it did before budgets existed.