AI models 2026: which one we use for what.

There's one question we invariably hear during the first audit call: "But do you use ChatGPT?". The short answer is no. The long answer is the technical architecture with which we ship autonomous systems to production in twenty-one days. Worth explaining in full, because this is the point where an AI vendor stops being interchangeable.

The "single model" lie

The mainstream market is obsessed with "the best model overall". There's a constant race to establish whether the latest GPT-5 has been beaten by the latest Claude Opus 4.7, whether Gemini 3 is faster on a specific benchmark, whether a new frontier model has finally shifted the ranking. It's a useful conversation for tech journalists, but completely irrelevant for anyone building production systems.

At Jigen we don't root for any provider. We use them all. Our infrastructure is built on a rigid engineering principle: task-driven dynamic routing. We don't send a complex maths query to the same model we use for cold email outreach. It would be like using a scalpel to drive a nail. The vendor proposing "we do everything on one model" is confessing they have never run a production system with real costs — because anyone who has run one knows them.

How Jigen orchestrates · the 2026 map

When we build an Aurora agent or automate a back-office flow, the brain of the system is an orchestrator that distributes tasks to specific models in real time. The map we use today:

1 · Long reasoning, complex analysis, heavy coding. For the manipulation of structured data, script orchestration and logical-mathematical tasks, our workhorse is Claude Opus 4.7. Its ability to rigidly follow complex instructions without derailing makes it the obvious choice for the deep engineering layer. It costs more than the others, but the quality/error ratio justifies it when the task doesn't tolerate regressions.

2 · Fast tool-calls, high-volume operational automations. For tasks needing medium reasoning but low latency and high volume — lead qualification, email classification, structured extraction from PDF — the workhorse is Claude Sonnet 4.6. Intermediate cost, twice the speed of Opus, quality sufficient for 90% of operational tasks.

3 · General reasoning, vision and unstructured PDFs. When the system has to interpret screenshots of legacy interfaces, analyse mixed image+text documents, or handle generic multimodal logic, we rely on the GPT-5 family. It's robust, predictable, has mature native tool-calls, and is the provider whose prices have dropped most rapidly over recent months — useful for high-volume tasks.

4 · Web search, fresh context, queries with temporal reference. For tasks needing information updated past the primary model's cutoff — competitor analysis, event monitoring, price benchmarking — we use Gemini 3 with its native search-engine access. The point isn't reasoning quality (Claude and GPT are comparable or better in many categories), the point is access to recent context in a single round-trip.

5 · Mass classification, binary decisions at high volume. For tasks needing only a yes/no output, a category among four, a threshold to apply, we use the small tiers — Claude Haiku 4.5 or GPT-5 mini. Cost: a fraction of the top tiers. Latency: under 200ms. Thousands of calls per second can be run without the task cost exceeding the task value.

Choice matrix · which model, why

For those wanting a quick grid, here is how we think about trade-offs. It isn't a universal truth — it's the pattern that works for the typical tasks of a 2026 production system:

The matrix isn't static. We review it quarterly — Q1, Q2, Q3, Q4 of every year — and when a provider releases a version that changes the quality/cost ratio on a task, we update the map. It's a practice that requires discipline: without scheduled reviews, the routing fossilises on choices made six months ago for reasons no one remembers anymore.

The competitive advantage of orchestration

Developing with this paradigm offers three asymmetric advantages.

Insulation from model wars. If tomorrow morning a provider raises prices by fifty per cent, or has forty-eight hours of downtime, our clients don't stop. The orchestrator performs an automatic fallback to the second-best available model for that specific task. The prompt is written in a provider-agnostic way (with small adapters for the specific tool-call syntaxes), the test is repeatable on two providers, the fallback is a one-second decision, not a three-month project.

Inference cost reduction. Instead of paying premium cost for a top model just to have it extract three entities from an incoming email (a task a small tier solves in milliseconds at near-zero cost), we reserve the heavy artillery only for high-level decisions. The difference, on real volumes, is enormous: a poorly orchestrated system using Opus for everything can cost forty times a well-orchestrated system on the same volume.

Speed of adoption of new releases. When a new model ships — Claude 4.8, GPT-5.5, Gemini 4 — we don't have to rewrite the system. We add the new provider as an option, test it on a subset of tasks, include it in routing if it passes quality/cost criteria. Average time to engage a new model in production: two-three days. Agencies that tied their architecture to a single provider take six months to migrate when the vendor changes terms — and in the meantime they pay the difference.

Real costs · example numbers

An anonymised example of a system running today in production for one of our clients. An inbound-lead qualification agent: receives an email, decides if it's target, extracts structured data, writes the first automated reply.

Poorly orchestrated architecture (single top model for everything):

• Initial classification "is this a real lead?" on Opus 4.7 → ~9 cents per call
• Data extraction on Opus 4.7 → ~12 cents per call
• Reply writing on Opus 4.7 → ~14 cents per call
• Total per lead: ~35 cents. On a thousand leads per month: ~350 EUR/month of inference alone.

Well-orchestrated architecture (same functional outcome):

• Initial classification on Haiku 4.5 → ~0.3 cents per call
• Data extraction on Sonnet 4.6 → ~3 cents per call
• Reply writing on Opus 4.7 (this is the task where quality matters) → ~14 cents per call
• Total per lead: ~17.3 cents. On a thousand leads per month: ~173 EUR/month.

Fifty per cent saving on the same functionality, with no measurable degradation of output quality. Real numbers, not illustrative. At volumes of tens of thousands of calls per month — the typical case of a medium client — the delta becomes the difference between a sustainable system and one the client stops using as soon as they see the first API bill.

The myth of proprietary data

Another buzzword agencies love to sell is the illusion of "creating your company's AI by training a model from scratch". It's an unjustified investment sold at a premium. In ninety-nine per cent of corporate cases, training from scratch produces a model inferior to the one you could use via API, costs ten times more, and becomes obsolete at the first frontier-model upgrade (which typically ships every three-six months).

We work with hyper-optimised retrieval-augmented generation architectures. We take the client's corporate knowledge, index it in a vector database, and feed it to the best model at that precise moment, providing only the context needed to act. The data stays with the client, the system is updatable in real time (without retraining anything), the result goes to production in three weeks instead of six months, and — key point — when the next model ships, the provider is swapped in thirty minutes, not three months.

Real exceptions to the pattern (where fine-tuning makes sense): domains with very tight technical vocabulary, where even frontier models show a measurable, repeated gap. Vertical legal, clinical pharma, complex proprietary code. There, fine-tuning is a decision taken after showing retrieval isn't enough, never before.

Data security · where it actually lives

A point many clients ask and few agencies explain honestly. The data flowing through an orchestrated AI system lives in three places, each with different rules:

Data with the client · always. The database with the corporate knowledge (documents, contracts, knowledge base) stays inside the client's infrastructure, on a cloud under their control. No document "travels" to the AI providers permanently.

Data in transit · ephemeral. When an agent makes a query, the AI providers receive the prompt — which includes the context retrieved by the RAG — and produce a response. By default, the enterprise terms of Claude, GPT and Gemini don't train their models on API data. Additional DPAs can be signed that block any storage of prompts. The client knows exactly which data passes, because every call is logged.

Data on-premise · only when mandatory. For regulated sectors (banking, healthcare with PHI, defence) self-hosted deployment options exist from providers, or open-source frontier models run on-premise. Costs more, requires more sophisticated ops, but in those cases it's non-negotiable. The vendor proposing "all cloud, trust us" without addressing the on-premise topic doesn't know what they're selling.

When NOT to switch models

The opposite temptation to monoculture is perpetual churn: every new model that ships, we rewrite the architecture. This is also a mistake. Changing a model in production has a hidden cost — prompt regression testing, real cost verification on client volumes, output validation on edge cases — that often exceeds the incremental benefit.

The operational rule we use: we change a model in production only if the new one offers at least fifteen per cent measurable improvement on the single task it's being evaluated for (quality, latency or cost, not a vague mix), and if the cost of switching is recouped in less than thirty days of execution. Below this threshold, the current model stays. Churn without criteria costs more than obsolete models.

Quick test · is your vendor really multi-model?

A diagnostic grid for the leadership of a company evaluating an AI vendor. Five questions:

1. How many different providers does your system touch on a typical day? Healthy answer: at least two (more realistically: three or four). Suspicious answer: just one.
2. If the primary provider goes offline for twenty-four hours, what happens to my system? Healthy answer: automatic switch to the second provider within minutes, possibly with documented partial degradation. Suspicious answer: "it has never happened".
3. What is the cost per call, today, on each task type of my system? Healthy answer: a table with real numbers. Suspicious answer: "depends on volume" without a figure.
4. How do you handle the arrival of a new model? How long does it take to integrate it? Healthy answer: existing validation pipeline, deployment in two-three days. Suspicious answer: "we evaluate case by case" without timelines.
5. Can I see the structured log of a call? Which model handled it? Healthy answer: yes, on a dashboard, with prompt + model version + cost. Suspicious answer: "logs are internal".

Three healthy answers out of five mean a competent vendor. Two or fewer mean the vendor is improvising — and when the price of the model they use rises, they'll find out only when the bill arrives.

Don't buy "Artificial Intelligence". Buy an engineering infrastructure built to handle growing volumes, defend you from provider downtime, cut inference cost, integrate new models without rewriting the system. It's the only thing that matters for your net margin — the rest is pitch jargon.

Jigen reading: the model map above is ours as of 2026-Q2. It's bound to change — every quarter we review quality/cost/latency benchmarks and update routing. The vendor locked to a single provider or never updating their stack is making a bet that in six months will cost dearly. Multi-provider isn't a luxury architectural option — it's the minimum default for a 2026 production system.