Every week there is a new benchmark, a new leaderboard, and a new claim that one model has overtaken the others. None of this matters for production. The question for a working system is narrower: which model gives you the right answer often enough, fast enough, and cheaply enough, on your specific workload. Here is how we decide.
Start from the workload, not the model
The mistake almost everyone makes is picking a model first. The right starting point is the workload. Three questions sort most cases:
- Is this a synchronous user-facing interaction (chat, search) or an asynchronous one (batch processing, an overnight agent)?
- How long is the typical context, and how often does it spike?
- How critical is tool use - does the model need to call functions, browse, or use MCP servers reliably?
The answer to those three usually narrows the field to one or two real candidates.
Where each one tends to win
These are working observations from projects we have shipped, not a benchmark claim.
Claude consistently wins for us on agentic work - long, multi-step tool use, reasoning over messy context, drafting where tone matters. It is also our default for anything where we want the model to be honest about uncertainty rather than confidently wrong. The 1M-token context option matters for some workloads, but more often the win is in instruction following over long, complicated prompts.
GPT is the strongest all-rounder for general-purpose chat, image generation, and use cases where the OpenAI ecosystem (assistants, files, batch) is a real productivity boost. The reasoning models are excellent for hard one-shot problems where latency is not the bottleneck.
Gemini wins on cost at scale and on truly massive context. If you need to feed a model a 500-page document and ask questions about it, or if you are running millions of cheap classifications, it is hard to beat.
Cost and latency are decisions, not afterthoughts
A model that costs ten times more and is twice as smart is not always the right call. We routinely route different parts of the same workflow to different models - a small model for triage, a larger one for the final draft, a reasoning model only when the problem actually requires it. This kind of cascade is one of the highest-leverage patterns in production AI work and a reason “which model do you use” is rarely the right question.
Latency is similar. A user-facing chat that responds in 800ms feels alive. The same system at 4 seconds feels broken, regardless of how clever the answer is. Always test the model in the actual interaction, not just the API.
Lock-in and migration risk
We assume any model choice will need to change within twelve months. Prices fall, new versions ship, providers go down. We build with a thin abstraction over the model call, evals that are not tied to a specific provider, and prompts that are written to be portable. The cost is small; the optionality is large.
How we help
We pick models for client systems based on the actual workload, build the cascading routing where it pays, and keep the architecture portable so the choice can be revisited as the market moves. If you are about to commit to a single provider for a major system, an outside view is usually worth the conversation - especially before the contract is signed.
Tags