Most products that put a model behind a chat surface in 2026 reach for the smartest available frontier model. Cambio runs on Gemini 2.5 Flash Lite. Here is the actual engineering tradeoff that led to that choice — including the period we spent on a different fast-tier model first — and the conditions that would make us change our mind again.
When you decide to put a language model behind a product surface in 2026, the loudest default is to use whichever frontier model has the highest score on the leaderboard of the month. Claude Opus 4.7, GPT-5, Gemini 2.5 Pro Ultra — these are the names that come up when product teams discuss "which AI." Smarter is better, the reasoning goes, and the cost difference disappears at scale.
Cambio runs on Gemini 2.5 Flash Lite. Not the reasoning variant, not the frontier variant — the smallest fast-tier model Google ships, sitting underneath Flash and well underneath Pro. We made that decision deliberately, after evaluating the obvious alternatives and running a previous fast-tier model (xAI's grok-4-1-fast) in production for several weeks. This post is the actual engineering reasoning behind the current choice, the conditions that drove it, and the conditions that would make us revisit again.
What the model has to do at Cambio
Two jobs, both bounded. Neither is reasoning-heavy.
The first is parsing. The model takes a short user message — typically 5 to 30 words — and extracts structured fields: category (Swap, Execute, Suggest, Compare, Help, Explore), from-currency, from-network, to-currency, to-network, amount, direction. Most cases are handled by a regex layer that runs without the model. The model is invoked when the regex is uncertain. The output is a JSON object with at most seven fields.
The second is narration. The model receives a structured quote object (the rate, the competitor strip rows, the settlement window, the chain-aware spread, whether the Best Rate pill renders) and produces a one-sentence explanation in natural English. The output is one or two short sentences, never more than 40 words.
Neither job involves multi-step reasoning. Neither job requires the model to choose between many alternatives. Neither job has the model interacting with tools, calling APIs, or holding state across turns. The capability requirements are: read a short prompt, follow a structured output format, produce coherent English. Every modern language model can do this, including ones launched two or three years ago.
Why frontier reasoning models are the wrong tool here
When we benchmarked the candidates, we ran identical eval batches against Claude Opus 4.7, GPT-5, Gemini 2.5 Pro Ultra, and Gemini 2.5 Flash Lite. The capability ceiling on parse correctness and narration quality maxed out around 99.4-99.6% on every model. The frontier models scored marginally higher on the most ambiguous prompts — the kind where the message is genuinely unclear — but the marginal gain was a few tenths of a percent on a workload that already had a regex pre-filter handling the easy 95%.
The cost picture was less marginal. Per million tokens, the frontier reasoning models in 2026 are priced roughly 8x to 20x the fast variants. The latency picture was even less marginal. P95 first-token latency on Claude Opus is in the 800-1500 ms range; on GPT-5 it is 600-1100 ms; on Gemini 2.5 Flash Lite it is 120-300 ms. For a product where the total composer round-trip is supposed to be under 200 milliseconds, a model that takes 600 ms to start its first token is structurally incompatible.
A 99.5% parse rate at 200 ms is a better product than a 99.7% parse rate at 800 ms. The user experience curve is dominated by latency in the range we operate in. Once the model is fast enough and right enough, more "smart" is wasted budget.
Why the fast tier in general
The shortlist of viable models for Cambio's jobs comes from the fast tier across providers: Claude Haiku 4.5, GPT-5 Mini, Gemini 2.5 Flash Lite, grok-4-1-fast. All four are capable enough on the parsing and narration benchmarks. All four are fast enough to fit in our latency budget. All four are cheap enough that the per-quote cost is negligible at our launch volume.
At that point, the decision is less about model capability and more about operational fit. We evaluated four axes: cost per quote at launch volume, structured-output reliability, latency under realistic provider load, and the practical health of the provider's SDK and rate-limit posture.
Why Gemini 2.5 Flash Lite specifically
On cost: Flash Lite is the cheapest of the four on our specific input/output token mix. Cambio parse calls are short input, short output, and Flash Lite's per-million pricing on this symmetric short/short pattern beat Haiku, GPT-5 Mini, and grok-4-1-fast by ~20–60% at the per-call level. At launch volume the absolute difference is single dollars per day across all four; at projected post-launch volume the gap is meaningful.
On structured-output reliability: Google's `responseSchema` JSON mode is the most disciplined of the four. We measured how often each model returned a parseable JSON object that matched our schema on the first attempt for our exact prompt template. Flash Lite tied with Haiku at the top (>99.5%); grok-4-1-fast was just behind (~99.3%); GPT-5 Mini lagged (~97.8%). The 1.7 percentage points difference between top and bottom is real money — every malformed output is a retry, which doubles the latency for that user.
On latency under provider load: Google has the largest serving footprint of any of the four providers. P99 first-token latency on Flash Lite stayed under 350 ms during US business hours in our load tests, with no measurable queue contention. The other three providers have all shown 5–15 second cold spikes during high-traffic windows in the last six months. We are not arguing the underlying models are slower; we are arguing the contention posture is materially better on Google's infrastructure.
On the prior production run: we shipped the first version of Cambio on grok-4-1-fast and ran it for several weeks. It worked. The switch to Flash Lite (commit on 2026-05-27) wasn't about Grok being wrong — it was about Gemini being measurably better on the four axes above by the time we re-ran the eval suite. The agent layer is provider-agnostic: xAI and OpenAI are still selectable behind a config flag, and the test harness continues to stub all of them. If Gemini ever regresses we can flip back in one config change.
Why not the reasoning variant
Gemini 2.5 ships a thinking-mode variant. We do not use it. Thinking mode is designed for problems that benefit from chain-of-thought — multi-step problems, problems where the model has to consider alternatives, problems where intermediate scratch-pad steps improve the final answer.
Neither of our two jobs is that. Parsing a short user message into seven structured fields does not benefit from a reasoning step. Narrating a structured quote object into a one-sentence explanation does not benefit from a reasoning step. Thinking mode would add 300-800 ms of latency for a quality improvement we cannot measure. We tested both. Non-thinking output was indistinguishable in quality and ~3x faster.
Our internal notes pin this preference explicitly. Production runs `gemini-2.5-flash-lite` with thinking off; dev and test always stub the LLM entirely via `AGENT_STUB_LLM=true` so the harness never bills tokens. The default was added after an early version of the assistant accidentally got pointed at a thinking-mode variant and latency on the composer doubled overnight. The fix was a one-line config change. The lesson is durable: for our jobs, reasoning is overhead.
What we are giving up
Honest disclosure of the trade-off. By not using a frontier model, we are giving up the marginal capability on the most ambiguous prompts. A user who types something genuinely confusing into the composer might get a slightly worse clarifying question from Flash Lite than they would from GPT-5. We are also giving up access to certain advanced features the frontier tier offers — million-token context windows, complex tool-calling chains, deep multimodal reasoning — none of which matter for our jobs but which would matter if we ever expanded the model's scope. (We won't, per the previous post in this series.)
The trade-offs we are not making: we are not giving up parse correctness on the common case, we are not giving up narration quality, we are not giving up latency, we are not giving up cost predictability. The 0.2-0.5 percentage points of marginal capability we lose to choosing a fast model over a frontier one is a price we are happy to pay.
When we would revisit
A few specific conditions would make us reopen the model selection again.
If Flash Lite latency degrades materially — say, p95 climbs above 600 ms during peak hours and stays there for more than a week — the latency budget breaks and we switch. Our evaluation harness runs continuously against all four shortlist models with our exact prompt template, so we have current numbers at all times.
If we add multilingual support and Flash Lite's quality drops more than the other fast-tier models on the specific languages we add (Spanish, Russian, Chinese are first), we may go multi-provider — Gemini for the primary English path and a different model for languages where it underperforms. The agent layer already supports this routing.
If pricing changes substantially — say Google raises Flash Lite rates 5x or a competitor cuts to a tenth — we revisit the cost axis. We will not switch for a 10% pricing difference, but a structural shift matters.
If a new model from another provider clearly beats Flash Lite on our specific eval suite (the parsing benchmark and the narration benchmark on our actual production prompts, not generic leaderboards), we switch. We run the eval suite monthly. The last time we did, Flash Lite won every relevant cell — which is how we ended up here in the first place.
The general lesson
Choosing a model is a workload-specific decision, not a brand decision. The "best" model for a product depends on the shape of the prompts you are sending, the latency budget you have, the structured-output discipline you need, the cost envelope at your scale, and the provider posture you can live with. None of those things are visible in a leaderboard. All of them have to be measured against your actual workload — and re-measured periodically, because providers ship new fast-tier models every few months and the answer can move.
For Cambio's shape — short symmetric prompts, hard latency budget, two narrow jobs that do not need reasoning — Gemini 2.5 Flash Lite is the right answer today. For a different product with a different shape, the right answer is genuinely different. If you are building anything similar, the takeaway is not "use Gemini Flash Lite." It is "build a provider-agnostic agent layer, test the fast tier against your actual workload, and re-run the test every quarter."
The final post in this series goes deeper than any so far: how Cambio settles cross-chain swaps without using bridge contracts, and why that is a fundamentally different operational profile than the architectures that the rest of the industry uses for the same job.
