The model race is really a budget race

Reuters reporting on competition between Anthropic and OpenAI provides the backdrop. This analysis does not rely on unverified spending percentages, release deliberations or IPO timing.

A spending sample is not the whole market and does not establish which model is right for a particular workflow. The useful comparison is the cost of work your team accepts.

Notice what is being used as the measure of a model's success. Not a benchmark. A share of corporate spending. The frontier labs are now competing for a line in your budget, so purchasing decisions deserve commercial scrutiny as well as technical evaluation.

For a buyer, that is good news and a trap at the same time. Good, because competition keeps prices falling and capability rising. A trap, because it is tempting to marry the leader of the month.

Build for model portability. Keep prompts, evaluations and data access behind your own interface so swapping a model is a configuration change, not a project.

Run your own evaluation on your own work. Public benchmarks do not know your customers, your language or your risk appetite.

Buy capability, not loyalty. The right posture in a race this fast is to stay cheap to change.

In every transformation I've worked in — from shipping to grocery retail — the technology changed faster than the organisation. The companies that won built for change, not for one vendor.

More on the patterns behind that in the keynote, and the cases it's built on in my work.

Build a small evaluation set from tasks you can legitimately use: routine requests, ambiguous instructions and examples where the correct response is to ask for clarification. Write the acceptance criteria before comparing models. Have the people who use the output judge whether it is ready for the next step.

Compare total effort per accepted result, not just the price of a request. Include retries, human correction, response time and integration work. A cheaper response that needs rewriting may be the wrong purchase; an expensive model may be unnecessary for a tightly defined task. Let the task decide rather than applying one model everywhere.

Keep the evaluation set stable enough to compare releases, but review it when the work changes. Otherwise, you risk optimising for yesterday’s process while calling it progress.

Do not confuse being able to switch with maintaining two complete production stacks. Decide which dependencies matter: model-specific prompts, tool calls, stored context or contractual terms. Document how each would be replaced, and test the most important dependency before renewing the agreement.

There is a trade-off between using a distinctive vendor feature and keeping the workflow easy to move. Accept that dependency deliberately if the benefit justifies it. Ask who owns the exit plan and what evidence would trigger a change. AI advisory is a place to frame that build-or-buy decision; agent governance covers the controls that should survive it.