Model and cost controls

Every completed agent run answers two practical questions: which model did this work? and what direct model cost did it create? The run page shows the exact provider and model, whether the result came from the mock or approved real-model route, and one of three cost labels.

• Estimated means the provider's token counts were priced using the rate version in effect for that attempt.
• Reconciled means later provider billing evidence matched the ledger.
• Unknown means the platform does not have enough evidence yet. Unknown is intentionally not displayed as zero.

The number is direct variable model cost. It is not an invoice, an employee or department chargeback, or the full cost of operating the platform.

A mock run: the route line reads mock-local (allowlist_required, policy mock-zero-v1) because the user is not on the real-model allowlist, and the zero-cost mock model shows $0.0000 estimated.

Which route did this run use?

The card's route line records the decision the platform made before any model was called: Route: <route> (<reason>, policy <version>), followed by the run's data class and region.

The hosted demo has four approved real routes, one for each capability tier:

• Haiku 5.5: the economy route, the cheapest.
• Sonnet 5.5: the standard route.
• Opus 5.5: the frontier route.
• Fable 5.1: the apex route, the most capable.

Their route lines name policy m1-demo-v4. The price book holds these rates in US dollars per million tokens:

A run uses the cheapest route at or above its tier. An everyday task is standard and a complex or escalated task is frontier. A real-model run from the agent page keeps the authored tier, raised for a large input or more than two screenshots. A workflow step keeps its agent's tier, raised only for a large input, because workflow steps carry no screenshots. On the hosted demo both use Sonnet 5.5 or Opus 5.5. A real chat answer's model follows the person's choice: Auto and Fast use Haiku 5.5, Balanced uses Sonnet 5.5 and Thorough uses Opus 5.5. The reason is one of:

• only_candidate: exactly one approved route satisfied the run's requirements. This is the normal case when a deployment has a single real route; the hosted demo has four, so a real-model run there usually shows one of the next two reasons.
• cheapest_compatible: several approved routes qualified and the cheapest was chosen. On the hosted demo only an economy run shows this reason, and economy runs come from the chat's Auto and Fast.
• capability_floor: the run needed a higher capability tier than the cheapest route offers. On the hosted demo a standard run shows this reason, because Haiku 5.5 is cheaper, and so does a frontier run, because Haiku 5.5 and Sonnet 5.5 are cheaper.
• allowlist_required: the user is not approved for real models, so the run stayed on the zero-cost mock model.
• forced_mock: the run was explicitly pinned to the mock model, for example an agent test run.

A Haiku 5.5 prompt over 100,000 tokens is priced at the base rate, although Anthropic charges more above that size; the chat's limits keep prompts far below it.

The route decision never widens what the run is allowed to reach. A run's data class and region travel with it, and a route that does not meet them is never used.

Asking a stronger advisor

An agent can be allowed to consult an advisor model about a hard judgement. It is off unless two things are true: the agent's tool grants include engine:consult_advisor, and the deployment's advisor switch is on. The demo site has the switch on. The agent editor does not offer this grant yet, so it is added to the agent's saved configuration directly. In the support chat the Support Assistant holds this grant. It asks once before it answers a diagnosis or a request to change a production system, and again when the evidence does not add up; it does not ask for greetings, simple lookups or rewording.

• The advisor uses the same approved routes and the run's own data class, region, and cost ceiling. It can never reach a model the run itself could not use. On the hosted demo the advisor is one tier above the run: Opus 5.5 advises Auto, Fast and Balanced answers, which run on Haiku 5.5 and Sonnet 5.5, and Fable 5.1 advises Thorough answers, which run on Opus 5.5. On a deployment whose real routes are not the Gateway routes of the hosted demo, the advisor is switched off.
• The advisor sees the conversation's inputs and the tool results so far, never the retrieved documents.
• A run asks the advisor at most the configured number of times, set by ADVISOR_MAX_CONSULTS_PER_RUN (one by default, at most five). Each consult counts against the run's limits on tokens, cost and time, and a consult that would overspend any of them is refused rather than sent. Every consult reserves its cost before it is sent and counts toward the run's budget and cost evidence.
• When a consult is not allowed, because the switch is off, the run's consult limit is reached, the budget or the time left would not cover it, or no approved route fits, the agent is told so and carries on. The run's tool activity shows the consult as "advisor refused — the run continues". A refused consult never stops the run.
• Consults count toward the per-user rate limit on model calls, which the DEMO_REQUESTS_PER_MINUTE setting sets. A run that consults the advisor reaches that limit sooner.

The run owner and admins see each question and answer word for word on the run page, under Advisor consults in the Steps view, with the advisor model, the outcome, what the advisor saw, and the consult's tokens and cost. Other users cannot read them, and they are never written to the run's events.

A consult always runs on a different, higher model than the run's own, so it always has its own cost line, labelled advisor.

Checking chat answers

The answer check is off by default, and the demo site runs with it off. An administrator can turn it on for a deployment. With ANSWER_CHECK_ENABLED on, each Support Assistant answer on a real route is checked against its sources before the person sees it; Haiku 5.5 runs the check. An answer under 90%, or one that fails a behaviour check, is reviewed: an advisor model advises, the answering model rewrites the answer, and Haiku 5.5 checks the revision once. The review also needs the advisor switch. With the check off, or on a mock or local provider, nothing is checked and nothing extra is spent.

The platform reserves before it spends and counts every prompt byte as a token, so a step reserves far more than it costs:

These are estimates. The run page shows each check's actual cost, and what rewriting the answer cost, under Answer check in the Steps view.

The check, the review and the revision are steps inside the reply run, so the same caps cover them as cover the answer: the per-run cap (DEMO_PER_RUN_USD), the per-user run cap (DEMO_PER_USER_RUN_USD), the daily cap (DEMO_DAILY_USER_USD), the monthly cap (DEMO_MONTHLY_USER_USD) and the rate limit (DEMO_REQUESTS_PER_MINUTE). A review starts only when the advice, the revision and the re-check all fit what the run has left; otherwise it is skipped and the first check's label is shown.

• A Haiku-led answer's review reserves about $0.18, which fits a per-run cap of $0.25 when earlier consults have not used the room.
• A Sonnet-led answer's review reserves about $0.27 and needs a per-run cap of about $0.60.
• A Thorough (Opus-led) answer's review reserves about $0.60 before its own draft, so it is skipped unless the per-run caps are raised to about $1.00.

A checked answer makes at least two model requests and a reviewed one at least five. Raise DEMO_REQUESTS_PER_MINUTE from its default of 3 to about 20 before you turn ANSWER_CHECK_ENABLED on.

How spending is controlled

Before a real model is called, Project Synapse reserves a conservative upper bound. One database decision checks the run cap, user/run cap, daily user cap, monthly user cap, and short-window rate limit. Their code defaults are $0.25 for the run cap and for the user/run cap, $1 for the daily user cap, $5 for the monthly user cap, and 3 model requests a minute; the demo site sets its own values. Concurrent requests cannot each assume they own the same remaining budget. If the platform cannot prove the call is within policy, it does not send the request.

The hosted demo runs the Gateway route profile: four approved real routes (Haiku 5.5 as the economy route, Sonnet 5.5 as the standard route, Opus 5.5 as the frontier route, Fable 5.1 as the apex route), open only to explicitly approved user accounts. A deployment's active route profile decides which real routes exist, so another deployment can have different ones. Everyone else stays on the zero-cost mock model. The real-model kill switch can stop new paid calls immediately.

What the cost record does not contain

The financial record contains identifiers, token quantities, rates, cost, policy version, and provider request correlation. It does not contain prompts, answers, documents, connector payloads, credentials, patient information, or other business content.

Cost-center budgets, which a run reserves against after these caps, and the spend showback pages are described in Spend showback & budgets.