I Delayed Multi-Model Orchestration. Then the Economics Changed.

In my previous article, I described how AI coding agents can generate software quickly while quality is maintained by the process: tests, CI, quality gates, review and human decisions.

At that time, I was still thinking mostly in terms of one provider and one primary coding agent.

I deliberately postponed advanced orchestration. Not because I considered it useless, but because the extra complexity did not yet seem justified. Every additional model means more configuration, more failure modes, more logs and more routing decisions.

For a while, one strong model was easier.

Then the economics changed.

One premium model for every task is wasteful

A coding workflow includes very different kinds of work: reading a repository, planning, implementing changes, generating tests, reviewing diffs, debugging failures and updating documentation.

These tasks do not require the same level of reasoning.

Using the most capable and expensive model for every step is like assigning a senior architect to every minor maintenance task. It works, but it does not scale economically.

The key question stopped being:

Which model is the best?

It became:

Which model is good enough for this step?

My current setup

My workflow is becoming a small multi-model production system:

• Codex / OpenAI coordinates work in the repository.
• DeepSeek V4 Flash is the default worker for fast and repetitive tasks.
• DeepSeek V4 Pro is the escalation path for harder implementation or reasoning.
• Gemini 3.1 Pro Preview can provide a second review or another perspective.
• OpenRouter provides routing, provider selection, logs and cost telemetry.

This is no longer a single AI assistant. It is closer to a small team of specialized models.

A recent test produced 57 requests, 344K tokens and a total cost of about $0.22. The cache hit rate was only 4.3%, so there is still room for optimization.

Routing matters more than the model list

A multi-model setup can easily become a model zoo. The goal is not to connect as many providers as possible, but to define roles and escalation rules.

Task enters the workflow
        |
        v
Flash model handles the default path
        |
        +--> result passes validation --> continue
        |
        +--> failure, uncertainty or high-risk change
                    |
                    v
             Pro model escalation
                    |
                    +--> optional second review
                    |
                    v
             quality gates and human decision

The cheaper model is not trusted blindly. Tests, static analysis, architecture guards and review determine whether its output can move forward.

This follows the same principle I used earlier:

The agent may generate the change, but the pipeline decides whether the change is acceptable.

Orchestration adds one more rule:

The router decides which agent should attempt the task first.

Why I waited too long

My earlier concern was technical complexity. The new pressure is operational cost.

Agentic workflows are chains of calls. One request may trigger planning, implementation, testing, review, correction and documentation. Even when every call is affordable, the complete workflow can become expensive.

At that scale, routing is no longer a luxury. It becomes part of system design.

The architecture must balance quality, latency, cost, provider availability, context size, retries and auditability.

The best model should still be used—but only where its additional capability creates real value.

From choosing models to managing production

I no longer want to select one model for the entire workflow.

I want to manage a portfolio of models, each with a defined role, budget and escalation path.

The human role changes as well. The work becomes less about prompting one assistant and more about designing the production system: classifying tasks, setting routing rules, controlling budgets, observing failures and deciding when escalation is justified.

That is why orchestration now feels like the natural next step after quality gates and CI.

First, I learned how to control the output of coding agents.

Now I am learning how to control which agent receives the task in the first place.

Final thought

For small experiments, one powerful model is often enough.

For continuous agentic software development, it may be the most expensive possible default.

The future is probably not one best model.

It is a well-managed system in which several models cooperate under clear technical, quality and economic constraints.

How are you approaching this today: one trusted model, manual switching, or automated routing?