Model Arbitrage

What It Is

Model arbitrage is the deliberate act of routing different phases of an AI task to different models based on what each model is actually good at and what it costs. It is not the same as model routing, which is an architectural decision baked into an agent’s design — usually automatic and invisible to the operator. Arbitrage is a conscious operator choice, made mid-session or mid-workflow: this phase does not require the premium model’s full capability, so I am not paying for it.

The term borrows from financial markets, where arbitrage names the act of capturing price differences in equivalent assets across two venues. In AI work, the “asset” is useful output at a given quality level, and the “market” is the token pricing each model charges to produce it. A planning step that requires broad synthesis but not deep reasoning is a task where a mid-tier model can perform at 90% of a premium model’s quality for 10% of the cost. That gap is the arbitrage. Running the full pipeline on a premium model because it is the default is leaving that gap on the table every time.

The practice has been technically possible for years — operators could always switch between different API keys and providers — but it became fast and practical only when tools like OpenCode introduced provider-agnostic model switching inside a single session. As of June 2026, switching models mid-task in a provider-agnostic agent is a single typed command, with no session restart and no context loss.

How It Actually Works

In a provider-agnostic agent with access to multiple model providers, model arbitrage works like this: you run the planning phase with a cheap, fast reasoning model. When the plan is solid, you type a command to switch to a mid-tier model for implementation. When implementation is done, you switch again to a local or inexpensive model for code review and consistency checking. The same project state, the same codebase, the same conversation history — a different model finishes each step.

In a tool locked to a single provider, arbitrage still happens but requires spinning up multiple tools: draft the plan in one, implement in a second, review in a third. The cost of the context switch is friction, not impossibility. The operator who pays for multiple subscriptions and routes tasks deliberately across them is already practicing model arbitrage, whether or not they call it that.

The variable that determines whether the arbitrage works is context handoff. When switching models mid-task, the new model needs enough context to understand the prior work without re-solving the whole problem. A structured summary — what the plan is, what has been done, what constraints the output must satisfy — costs a few hundred tokens and prevents the new model from starting from scratch. Without the handoff, the output at the seam is incoherent. With it, the seam is invisible.

The Cost/Tradeoff

The primary gain is cost reduction without proportional quality loss. An engineering task that would cost $8 to $12 in pure premium-model tokens can often be completed for $2 to $3 using phase-aware routing: a fast reasoning model for planning, a mid-tier model for implementation, a local model for review. The agent-loop-cost on the planning step is negligible for most tasks because planning-phase quality is bounded by the clarity of the spec, not the intelligence of the model. When the spec is clear, the cheap model plans well. When the spec is ambiguous, the expensive model still struggles.

The primary risk is switching at the wrong phase boundary. If the operator moves to the cheaper model before the hard reasoning is done, the cheaper model will produce plausible-but-wrong output that is difficult to catch at review. The right switching point is after the plan is verified and before the mechanical implementation begins. The second risk is overhead: every context handoff introduces summary tokens. A workflow with four model switches and four structured summaries may recover less of the cost advantage than a workflow with one clean switch at the right boundary.

A Concrete Operator Scenario

You are preparing a quarterly business review: twelve slides, six departments, each requiring factual summary and narrative framing. The data pull and factual summary for each department is rote aggregation: load the numbers, list the trends, flag the outliers. That is a mid-tier model task — fast, cheap, accurate on structured data. The narrative framing — which trend to lead with, what to flag for the board, how this quarter’s numbers connect to the annual thesis — requires editorial judgment. That is a premium model task.

Run them in sequence. The mid-tier model builds the factual skeleton of all twelve slides. The premium model receives the skeleton and a brief of what the board needs to understand, and it rewrites the narrative framing for each department. Final proofreading and consistency checking goes back to the cheapest model that can reliably run a checklist. You pay premium rates for six framing decisions. You pay mid-tier rates for the other fourteen steps. The twelve slides cost roughly what two slides would have cost on the premium model alone, and the output at every slide reflects the premium model’s judgment on the thing that actually needed it.

Common Misconceptions

“This is just model routing.” Model routing is an architectural decision: a pipeline designed so that task type A always goes to model X, automated at build time. Model arbitrage is an operator judgment: mid-session, you recognize this particular step does not need the expensive model and you switch. One is infrastructure; the other is craft. A well-designed agent may incorporate both.

“You lose quality by switching.” Quality loss happens only if you switch at the wrong phase boundary. The goal is not to minimize cost at every step. It is to pay premium rates only where the premium model’s output is genuinely different from what the cheap model would have produced. The judgment call is identifying that boundary.

“This only matters for developers.” Any operator doing multi-step AI work with distinct phases is a candidate. The business review scenario above has nothing to do with code. The principle applies wherever there are tasks with different intelligence requirements in sequence: research, then synthesis; outline, then prose; brainstorm, then critique. The developer use case is where the tooling makes arbitrage fastest. The principle scales to anyone with a subscription and a workflow.

How TWO Uses It

Founder’s Take: Every token dollar spent on a step the mid-tier model could have handled is a dollar you cannot spend on the step that actually needed the expensive one.

TWO’s production digest runs a version of this across every edition. Research and initial outline go to a mid-tier model with good search capability. The wisdom sourcing — where non-obvious connections and precision of interpretation matter — goes to the premium model. The structural audit (word count, link verification, tone pass) goes to the cheapest model that can reliably run a checklist. The total cost is roughly 40% lower than running the full pipeline on a premium model for every step. The output is indistinguishable.

The operator decision that matters is not which model to use by default. It is which phase of the work actually requires intelligence, defined as what a cheaper model genuinely cannot produce at the required quality, and to treat everything else as commodity compute. Premium models are not always smarter. They are sometimes just slower and more expensive at a task the mid-tier handles equally well. Knowing the difference is the skill model arbitrage is training you to develop.