18 August 2026
Choosing your LLM in 2026: GPT, Claude, Gemini, open-source — how I decide
My practical framework for choosing GPT, Claude, Gemini or open-source models in production: task fit, latency, cost, evals, context and EU constraints.
I never choose a model in the abstract
When someone asks me which LLM is best in 2026, I rarely answer with a model name. I answer with a question: for which business action, inside which product, with what tolerance for error, what acceptable latency, and what cost per successful outcome? GPT, Claude, Gemini, and open-source models are all moving quickly. The right decision is not to follow the leaderboard of the week. It is to choose the model that makes one precise system reliable, fast, and maintainable.
I work as a product-minded AI engineer, so my instinct is to bring the conversation back to the field. The user clicks, waits, reads, corrects, approves, or abandons. A model that looks extraordinary in a demo can be wrong for a frequent workflow if its answers are too long, if tool use is brittle, or if cost forces the team to ration usage. A less dramatic model can become the best choice when it holds the format, responds quickly, and fits cleanly into the product.
I start with the job to be done
My first filter is the shape of the task. For long-document summarization, I look at context handling, source discipline, and output stability. For code generation, I look at repo understanding, diff quality, and how easy it is to recover after a failed build. For an agent that manipulates tools, I care less about beautiful prose and more about discipline: calling the right tool, with the right parameters, at the right time, then explaining plainly what happened.
At Brut, an editorial assistant did not need the same model as an internal research agent. The first one needed to produce a clear suggestion, in a specific tone, very quickly, with little friction for a team used to time pressure. The second could afford a few more seconds if reasoning and sourcing were stronger. At Ellipse, use cases around story bibles, characters, episodes, and production continuity asked for another balance again: memory, nuance, rewriting, and respect for a creative universe.
The best model is often a portfolio
I still see many teams searching for one model to do everything. In production, I almost always prefer a portfolio. A fast and economical model handles simple classification, short extraction, rewriting, and format checks. A stronger model enters for hard tradeoffs, long synthesis, multi-step reasoning, or high-stakes conversations. A specialized model may complete the system for embeddings, reranking, vision, or structured generation.
This approach protects the product. It improves quality without letting costs explode, and it adapts intelligence to the real risk of the task. An automatic comment in an internal back office does not always deserve the most expensive model. A recommendation that influences an important client decision deserves more context, more validation, and sometimes a second pass. I therefore think in decision chains: which model on the first pass, which model for verification, which fallback when confidence drops?
Latency is a product feature
I measure latency as a user sensation, not only as a server metric. A model can be perfectly acceptable at eight seconds for an asynchronous report, and painfully slow at two seconds in a conversational interface that requires several turns. I look at p50, p95, timeouts, retries, streaming, and above all the moment when the user receives the first useful value. Perceived speed matters as much as raw speed.
That is often where the model choice changes. A very powerful model may be the right engine to prepare a plan in the background, while a lighter model replies in the interface and keeps the rhythm. At Brut, this is practical: a content team does not want to wait for invisible reasoning when it only needs a title variation or an alternative angle. On the other hand, for a heavier corpus analysis before an editorial meeting, waiting a little longer can be an excellent tradeoff.
Cost is decided per outcome, not per token
I do look at token prices, but I treat them as an incomplete signal. The real cost is the cost per successful action. If a cheap model fails more often, forces more retries, needs more defensive prompting, or increases human review time, it can cost more than a premium model. Conversely, when a task is tightly framed, a compact model with a good output schema can create a huge saving without any visible loss for the user.
My calculation also includes hidden costs: observability, caching, trace storage, evals, routing, supervision, incidents, support, and engineering time. Open-source or open-weight models can be excellent when volume, confidentiality, or customization justify the infrastructure. But hosting, GPUs, optimization, upgrades, and on-call ownership are part of the bill. The right comparison is managed API versus the total system operated by the team, not free versus paid.
Long context does not replace architecture
Large context windows are extremely useful, but they do not remove the need for design. Dropping the whole folder into the prompt feels reassuring at first, then becomes fragile: noise, cost, latency, conflicting sources, diluted instructions. I use long context when it truly serves the experience, for example to compare several documents, review a full history, or keep a complex conversation coherent. For the rest, I prefer clean RAG, state summaries, deterministic tools, and explicit business objects.
The question is not only how many tokens the model accepts. The question is what it does with the important information inside the noise. In a production environment like Ellipse, where teams work with characters, story arcs, and creative constraints, the model has to preserve the details that create continuity. So I test retrieval, source hierarchy, and the ability to say that information is missing. Context is raw material; architecture turns that material into a reliable decision.
Tools and evals separate the finalists
When two models look close, I separate them with production evals. I build a small set of real examples: easy cases, edge cases, bad documents, ambiguous instructions, out-of-scope requests, structured outputs, tool calls, and business expectations. I measure success, source precision, JSON stability, tool errors, latency, cost, and recovery quality after failure. That suite is worth more than a good impression after ten successful chats.
Tool-calling reliability is often decisive. An agent can write elegant text and still create the wrong action if it fails the schema. I test required parameters, enums, date formats, retries, useful refusals, and fallback paths. The model I choose is the one that respects the product contract. Evals do not remove human judgment; they make that judgment repeatable, shareable, and defensible with the team.
European data constraints are part of the design
In France and Europe, I bring data constraints into the discussion early. Some tasks can use a public API with anonymization, a clear retention policy, and the right contract. Others require a specific region, a particular cloud, processing without personal data, or a model hosted in a controlled environment. This is not a brake on innovation. It is how you build a product the company can actually adopt.
My final choice therefore looks like a simple matrix: task fit, observed quality, latency, cost per success, context window, tool reliability, data constraints, operating effort, and product trajectory. I keep GPT, Claude, Gemini, and open-source in the conversation, then choose the smallest system that delivers the right level of confidence. It is less spectacular than a fan-club debate, but it is how I see good AI products reach production and stay there.