When to Spend Frontier Tokens on Analytics Agents

Most analytics teams do not have a model problem. They have a default problem. The chat UI offers one box. The box is wired to whatever is currently impressive. “What was net revenue last Tuesday?” and “why did net revenue change, which definition applies, and what do we inspect next?” pay the same bill.

GPT-6 Astra’s list rate in the API is $10 per million input tokens and $50 per million output, higher for a faster mode. That is a scarce instrument. Using it for a named metric with a signed SELECT is how you train the company to think AI is expensive and still get the grain wrong. Using a tiny model for a six-step incident review is how you train the company to think AI is cheap and still ship a story.

Leave with a policy, not a vibe. The policy is: route by question shape and tool count, not by launch week.

Three workloads, three bills

Write this table on the wall. Argue about the borders. Do not argue about brand names.

Workload	Sounds like	Fit	Token posture	Failure if you mismatch
One governed question	Approved metric, known grain, one SELECT	Small or mid model	Schema snippet + query. No extracts in the prompt	Frontier bill for a lookup; team stops asking
Multi-step investigation	Variance, join choices, plots, failed hypotheses	Frontier or high-reasoning setting	Tools return projections. Notebook is memory	Cheap model flattens the story; reviewer cannot see attempts
Document-heavy evidence	Contract + tickets + an exception table	Frontier long-context, still filtered	Retrieve then quote. Do not load the archive	Dump cost, distractors, a clause from 2022 treated as current

A cheap model that emits correct SQL against a tight schema often beats a frontier model that narrates an unscoped join. Discounted and local models have already won narrow text-to-SQL cost contests in public writeups this year. Useful. Not a reason to run incident review on the cheapest completion.

Paying Astra rates to re-summarize a dashboard the team already trusts is waste. The dashboard did the aggregation. The agent’s job, if any, is the next question.

A practical mix many teams land on after they look at traces: small model for “fetch the signed metric,” frontier for “explain the residual.” The first is a lookup. The second is a search. Lookups should be boring and cheap. Searches can be expensive if they leave SQL behind. If the expensive path does not leave SQL, you paid for a story. Stories do not survive controllers.

Napkin math (use your real rates)

Suppose a “dump the last 90 days of events” prompt is ~800k input tokens and the model replies in 2k output tokens, then retries twice because the first join was wrong.

At $10 / $50 per 1M: three loads ≈ $24 input and a few dimes of output. That is the successful waste. The hidden waste is the hour a finance partner spends distrusting every later number.

The same question as a 1.5k-token catalog, one 80-token SQL, and a 2k-token aggregate: well under a dollar even at frontier rates, and checkable.

If 80% of your sessions are single SELECT, a frontier default is a budgeting error you will feel in the invoice before you feel it in quality. If 80% are incident-shaped, a cheap default looks thrifty in FinOps and fails in the war room.

Measure the mix. Guessing the mix is how defaults calcify.

A routing rule you can write down this afternoon

Start here. Add ML classifiers when the bill or the error rate forces you to. A second model that labels every utterance is latency and another failure mode.

1. Named metric + owner + time window → small model, one query path. Require visible SQL. If the catalog cannot resolve the name, do not guess. Ask which definition. Guessing is how “revenue” becomes gross.
2. More than one tool round (schema check, query, reshape, chart, caveat) → allow frontier or high effort. Cap iterations (for example 8). Cap rows returned to the model (for example 500). Cap bytes.
3. Writes, schedules, DDL, uncapped extracts → stop routing by intelligence. Route to a human. Model spend is a rounding error next to an unreviewed UPDATE.

Optional fourth line, once you have logs: if the last similar question reused a saved query, run that before any model. Deterministic beats generated when the question is a repeat.

Where the money actually goes

Sticker price is not the leak. Three mechanical leaks show up in every agent log.

Repeating the schema. Dumping every table comment into every turn is a warehouse tax. Cache a short, curated catalog per connection. Refresh on DDL, not on hello. If an agent needs information_schema every session, your context layer is a rumor.

Returning wide extracts. SELECT * into the prompt. The notebook can hold a frame. The model needs a projection. Wrapper-enforced LIMIT, column allow lists, and aggregate-first tools beat a paragraph in the system prompt that says “be concise.”

Compacting the evidence. Summarizing a long trace to save tokens deletes the failed join you need at 5 p.m. Compact chatter. Keep SQL. That is a full post later in this series; the routing implication is: do not buy frontier tokens to recover what you threw away.

A session log that makes routing honest

For the next fifty analytics sessions, record four fields. A spreadsheet is enough.

Field	Example
Question class	governed / investigation / documents / write
Tool rounds	1, 4, 11
SQL changed in review?	yes / no
Model tier used	small / frontier
Outcome	accepted / redefined / rejected

After fifty rows you will know whether your default is vanity. If governed questions are 70% and you still default frontier, you are buying brand. If investigations are 60% and you default small, you are buying speed and paying in rework.

Public benches will not give you this table. Only your traces will.

How this feels in a product that already splits the work

Kole is aimed at the investigation shape: SQL, Python, charts, and review gates inside Quantum Lab. Routing still belongs to the team that pays the bill. The platform should make the SQL and the tool trail inspectable so you can see whether the expensive model earned its keep.

You can implement the same policy in any stack that logs tool calls. If you cannot log tool calls, you cannot route. You can only hope.

See also: tools versus warehouse paste, long-context tests.

Take this home: question shape first, model second, writes never auto. If that sentence is now your default, the invoice will start making sense. If you want the traces to live next to the SQL instead of in a vendor dashboard, Quantum Lab is built for that.