Stage-based model routing

One task,
a model per stage

Choose models by task stage, with a record of what each request used.

Illustrative product interaction, not a live task or operational data.

task/router.checkout_refactor
routing
input signals · complexitymodel laneledger
  1. 01
    Search code
    read-only · one directory · low risk
    deepseek-v4.1-flash
    deep model
    1.2K
    —
  2. 02
    Analyse dependencies
    6 files · still read-only
    deepseek-v4.1-flash
    deep model
    2.8K
    —
  3. 03
    Core refactor
    payment path · several options · high risk
    deepseek-v4.1-flash
    deep model
    8.4K
    —
  4. 04
    Tests and wrap-up
    run tests · summarise changes
    deepseek-v4.1-flash
    deep model
    1.6K
    —
versus the deep model throughout
deep model throughoutprice pending
this mixed runprice pending
How it works

Code search and dependency reading run on deepseek-v4.1-flash; the refactors and debugging that decide quality go to deep model. You never switch models by hand: DeepCodex decides per stage and records the reason, spend and cost of every choice.

1
models
4
signals
100%
choices traceable

Decision signals

Four explainable signals drive the routing

Not random and not by price alone. Every choice shows its reasoning in the request detail.

Change scope

How many files and lines, and whether it crosses modules

Reasoning depth

Looking up a fact, or comparing several designs

Risk level

Whether it touches payments, permissions, migrations or other sensitive paths

Remaining budget

Whether this task and this period can still afford the deep model

In short:light signals → deepseek-v4.1-flash;heavy signals and budget allows → deep model;When the budget is short, results are never silently downgraded: the run stops and returns an explicit reason_code (for example quota_exceeded).

Savings estimator

Work out what this task saves

Enter tokens per stage; three baselines side by side: deep throughout, fast throughout, mixed.

Public unit prices are not published yet; the estimator is unavailable.

Three working modes

One engineering task, different execution strategies

The mode is picked by the platform per stage difficulty; the request detail records the model and spend of each stage.

MODE 01

Fast mode

deepseek-v4.1-flash

Search, summaries, formatting and small edits

Ratio:1×
MODE 02

Deep mode

deep model

Architecture, hard debugging and large refactors

Ratio:4×
MODE 03Recommended

Mixed mode

fast → deep → fast

Analysis first, core reasoning, then tidy-up

Ratio:by actual stage

Pipeline

One mixed task, three visible segments

The fast model does the frequent tidying, the deep model the quality-defining core, then the fast model wraps up.

01 · Quick read
deepseek-v4.1-flash

Read the task, extract the file scope, list known constraints

02 · Deep work
deep model

Compare designs, reason across files, generate the hard code

03 · Verify and wrap
deepseek-v4.1-flash

Format checks, change summary, structured result

Input
9.7K
Output
4.3K
Equiv. tokens
14K
Cost
price pending

equiv. tokens = fast tokens × 1× + deep tokens × 4×. However many times the model switches, the bill has one unit.

Routing policy

The model allowlist belongs to the key; routing is automatic by difficulty

Each key can restrict the model allowlist, concurrency, RPM and period cap. Automatic routing works only within the allowed models and quota.

  • Simple requests prefer the fast model
  • Complex tasks move to the deep model when the allowlist permits
  • Escalation stops before the budget is exceeded, with an explicit reason
  • Every stage records model, tokens, cost and duration
Production key / routing policyactive
Routing modeautomatic by difficulty
Model allowlistdeepseek-v4.1-flash
Period cap50M equiv. tokens

Speed, depth and budget on one chain

Automatic routing from the first request; every model switch is traceable in the request and task detail.