The Neutral AI Harness: Why Enterprises Are Building Around the OpenAI-Anthropic Swing

Source: openrouter.ai/data

The chart shows where developers are actually putting money across models. And that signal moved again.

The lead keeps changing

A year ago, our client conversations were split between ChatGPT and Claude. By early 2026, that had flipped toward Claude almost entirely, especially for coding and agentic work. It held through the summer.

Now OpenAI is back at the center of many of those conversations.

Whichever model a team has built around, the next release cycle can move the ground under it. One model gets better at coding, another gets cheaper, context windows expand, and tool use improves. A model that wasn't in the conversation six months ago suddenly becomes competitive for a production workload.

That exposure keeps showing up with clients regardless of which model they started with.

What it costs to keep switching

A team that has spent the past year building agent workflows around one lab's model has more sunk into that choice than the model itself.

The skills that tell the agent how to approach a task, the tool and data connections wired in, the context and memory handling, and the guardrails that decide what runs without a person watching are all tuned to how that specific model reasons and where it tends to fail.

Switching models means testing those assumptions again against a system that behaves differently. It also tends to expose just how many prompts, guardrails, fallbacks, and workarounds were built specifically around the previous model.

The API change may take an afternoon, but making sure the system still works the way the business expects can take a lot longer.

We're seeing that cost across client engagements this year, on whichever side of the latest swing a team sits.

Token costs are rising alongside it

Agentic workloads are also getting more expensive to run.

Longer tasks mean more turns. More turns carry more context. Agents call tools, inspect the result, reason about what happened, try something else, and keep going until the work is done.

At small volumes, it is easy to ignore the difference. At enterprise volume, the architecture starts showing up on the bill.

Costs can climb either way: staying on a model that has fallen behind on price or performance, or moving to a new one before the system around it is ready. A wrong model decision a year ago might have cost a few points of accuracy. At the usage volumes we're seeing now, it can mean a lot of engineering time and infrastructure spend.

Open models are widening the field

OpenAI and Anthropic aren't the only options clients are evaluating.

Open and open-weight models are increasingly part of the conversation, especially when the workload is predictable enough that running every request through a frontier model doesn't make economic sense.

A routine task may work just as well on a smaller model. A narrow domain task may be a better candidate for a model specialized around the company's terminology, data, and workflows. And some companies want more control over where a model runs and what happens to the data around it.

Open models are not automatically cheaper, since teams still pay for infrastructure, inference, monitoring, tuning, and deployment, but they give companies another lever.

Instead of picking one model for everything, the model portfolio can start to look more like the workload itself: smaller models for routine work, specialized models where domain performance matters, and frontier models for the hardest steps.

Our Model Fine-Tuning & Optimization work follows the same approach. We pair specialized open models with model portfolio optimization and route each class of work by performance, economics, and control, instead of sending every task to the largest available model.

What clients are asking us to build: a neutral AI harness

Clients keep asking us for the same thing, in different words: build it so the model underneath can change without the rest of the system changing with it.

They want routing that can send work to different models based on the task, the cost, and the performance they're seeing now.

They want tool and data connections built once rather than rebuilt every time they change providers. Protocols like MCP are helping there by creating a more consistent way for models and agents to interact with the systems around them.

And they want evaluation suites that give them a consistent baseline. If a team wants to test a new model, they can run the same tasks against it, compare the results, catch regressions, and understand the cost and latency tradeoffs before putting it into production.

The value is moving into the layer around the model

We think of that architecture as the Intelligence Layer.

It is the connective layer across company knowledge, data, systems, models, and agents. It handles the context, permissions, orchestration, evaluation, and governance that allow AI to work inside the business without every use case becoming its own isolated stack. It treats frontier, open, and specialized models as interchangeable parts selected for the job rather than forcing the enterprise onto one model provider.

With that layer in place, a company can benchmark the work it needs done, see where different models perform well, route accordingly, and keep watching quality, latency, and cost as the market changes. In some places that may mean fine-tuning an open model around a specific domain. In others, it may mean using a smaller model for the first several steps of a workflow and bringing in a frontier model only when the task requires it.

We've built engagements on Anthropic, OpenAI, Google, and open models this year because clients increasingly want that flexibility. No one knows which lab will have the best model six months from now, so the system should hold up when that answer changes.

The OpenRouter chart will move again.

If the architecture is right, the next swing is a routing change instead of another replatforming project.

FAQ