ChatGPT, Claude or Gemini? How to pick a model

The choice between ChatGPT (OpenAI), Claude (Anthropic) and Gemini (Google) matters less to your outcome than most people think — and far less than the quality of your data and the way the solution is built. On the work Danish companies actually use them for, the three are close together, and the ranking changes several times a year. So the decision that holds isn't "which model" but "how do we build this so the model can be swapped out in an afternoon". At Indee we pick the model per task and always build so it can be replaced.

Five criteria that actually decide it

Forget the benchmark tables. Five things move the decision in practice:

• The type of task. Long, connected documents demand something different from short classifications at high volume. If the model has to call tools and APIs, reliable tool use matters more than elegant prose.
• Data handling and compliance. Is there a data processing agreement? Can you run on EU-hosted endpoints? Is your data used for training? This often filters more brutally than quality does — see our walkthrough of GDPR requirements for AI in Danish companies.
• Latency. An internal report generator may take 30 seconds. A chat a staff member is waiting on in front of a citizen may not.
• Cost per call. The price gap between the best and the second-best model for a given task can be a factor of 5-10. On a solution making thousands of calls a day, that's the line that decides the operating budget.
• The ecosystem you're already in. If you already run on Azure or Google Cloud, there's real value in staying with what's integrated — in identity, logging and billing, not in model quality.

Choose per task, not per vendor

In practice most Danish companies end up using more than one model. A realistic picture:

That last row deserves a pause: open source is not free. You save the per-call fee and pay instead for GPUs, operations and updates. The maths only tips when volume is high enough, or when keeping data entirely in-house is non-negotiable.

Build for replacement

The technical advice with the longest shelf life: put a thin layer between your application and the model. One place in the code that knows which vendor is being called and what the response looks like. That turns a model switch into a configuration change rather than a project.

The same goes upward. Prompts written tightly around one model's quirks have to be rewritten at every switch. Prompts that describe the task clearly and return output in a fixed format rarely move.

Build your own test set — that's where the choice is settled

Public benchmarks say something about models in general and almost nothing about your task. What works is boring and effective:

1. Collect 20-50 real examples from your own day-to-day — including the hard ones and the rare ones.
2. Write down what a good answer looks like for each.
3. Run the same examples through two or three models and compare.

It typically takes a day, and it's the best day you'll spend in the whole engagement. The test set also becomes your safety net: next time a vendor ships a new version, you can measure whether it got better or worse at your specific task instead of guessing.

We use the same approach in Validi, where AI suggests journal notes to healthcare professionals. There it isn't enough for an answer to sound good; it has to be right on the actual cases the clinics have.

Frequently asked questions

Which AI model is best at Danish?

The large models from OpenAI, Anthropic and Google are all usable in Danish, and the difference is small on ordinary text. It becomes visible on professional vocabulary, abbreviations and domain-specific terms — and that you can only measure on your own examples. Run 20-50 real texts from your own work through two or three models before deciding.

Should we pick one vendor for everything?

Rarely. It gives simpler billing and fewer contracts, but usually costs you in both price and quality, because no vendor is best at everything. A sensible compromise is one primary vendor for most of it, plus the freedom — technically and contractually — to use another where it makes sense.

How often should we switch models?

Review it every six months, and switch only when your own test set shows a real improvement, or when pricing changes the maths. Chasing the newest model every month costs more in engineering time than it returns in quality.

---

Want help choosing and testing models on your own data? Book a no-obligation conversation with Indee — or see our services for what an engagement looks like.