Skip to main content

Replacement maps

Change the workflow only when the tradeoff works

A replacement is a hypothesis to test, not a blanket ranking. Use these maps to decide what to move, what to keep, and which comparison to run before switching.

Replacement map

Replace an expensive frontier model for routine coding

A high-end model can remain the escalation path while a cheaper tier handles tests, small fixes, and code explanation.

Run the comparison

Replace when

  • The task is bounded, repeatable, and covered by tests.
  • Your review data shows the cheaper model reaches an acceptable patch with fewer retries.
  • The work does not require the frontier model's long-horizon planning.

Keep when

  • The issue is ambiguous, cross-system, or expensive to get wrong.
  • The cheaper route creates more review work than it saves in tokens.

Replacement map

Replace an editor-only coding workflow with a terminal agent

Move only the tasks that benefit from delegation; keep short edits and navigation where the editor is faster.

Run the comparison

Replace when

  • You repeatedly hand off multi-file objectives and wait for a plan plus patch.
  • The team can review event logs, diffs, and tool calls in a terminal workflow.

Keep when

  • Most work is local, visual, and faster with inline feedback.
  • The beta agent adds coordination overhead without reducing review time.

Replacement map

Replace a closed API with open weights

Provider independence can be valuable, but only when the model, licence, and serving economics survive contact with production.

Run the comparison

Replace when

  • Privacy, deployment control, or predictable volume is a real requirement.
  • You can carry hardware, monitoring, upgrades, and model evaluation.

Keep when

  • A hosted API is cheaper after engineering and operations are included.
  • The open checkpoint is too large, too immature, or too restricted by its licence.

Replacement map

Replace a general model with a specialist for one workflow

Specialists can win on latency, cost, and predictable behaviour when the task boundary is narrow.

Run the comparison

Replace when

  • The input and output schema is stable enough to build a representative test set.
  • A smaller specialist reduces latency or cost without raising escalations.

Keep when

  • The workflow changes often or needs broad reasoning and fallback capability.
  • The specialist's maintenance cost is larger than the usage savings.