[iscekic]

bot: Put kilo-auto/frontier on the benchmark pipeline: the same router as efficient, with a frontier-only pool, its own harder tests and its own routing table. It ships behind a flag that defaults to off. This PR is stacked on #7518.

Change

• AutoRouter = 'efficient' | 'frontier'. /decide takes an optional router, which defaults to efficient.
• Isolated per router:
  • routing table (routing_table_v1 stays efficient; routing_table_frontier_v1 is new);
  • benchmark config, registry, runs and publish;
  • engine identity, which includes the router and its dataset hash;
  • sticky, classification and classifier-usage state.
• Shared: the classifier, billing, privacy and denied-model handling. Frontier ignores owner pools and coding-plan default shortcuts.
• Frontier benchmarks run FRONTIER_CASES (feat(auto-routing): sweep v2 with TTFT, long-context and frontier cases #7517).
• The cron and daily sync drain both routers. Concurrency budgets are per router, inside the shared container cap.
• Gateway: with the PostHog flag kilo-auto-frontier-routing on, kilo-auto/frontier asks /decide for a frontier decision. When the flag is off, the decision is null or the table is missing, the static FRONTIER_MODE_TO_MODEL mapping applies unchanged.
• Admin: the benchmarks page has a router selector.
• D1 migration 0016: adds the router columns. I hand-edited it: Drizzle's SQLite table rebuilds selected a router column that the old tables do not have, which would fail on deploy. They now select the literal 'efficient'.

Verification

• VM: contracts 119, auto-routing 303, auto-routing-benchmark 513 tests pass. Web gateway and admin Jest pass 239 tests. Typecheck passes, and type-aware lint is clean.
• Migration test: applied every earlier migration to a fresh SQLite database, seeded config, decider and profile rows, then applied 0016. All rows survive with router = 'efficient'.

Frontier sweep result (16 model/effort pairs across 8 frontier models, held-out frontier cases, agentic excluded)

Baseline: today's static mapping, with Sonnet at medium effort for code-style modes and Opus at medium for planning and asking. It is compared with picks rebuilt from the train split by this router's policy:

Metric	Change against the static mapping
Accuracy	+49%
Accuracy per dollar	+24%
Estimated cost per request	+20%
p50 latency	+38%
p50 TTFT	+22%

• The frontier cases separate frontier models: the static mapping scores about 0.56 on them.
• The policy optimizes quality per dollar inside the frontier pool, so it pays somewhat more for much higher accuracy. A cost cap is the lever if latency or spend must stay flat.
• Keep the flag off until the platform drain measures the frontier pool through the CLI container (agentic routes included) and publishes routing_table_frontier_v1.