---
type: "post"
id: "introducing-baseten-router-a-pareto-optimal-model-router-db4bc1"
slug: "introducing-baseten-router-a-pareto-optimal-model-router-db4bc1"
title: "Introducing Baseten Router: a Pareto-optimal model router for coding tasks"
description: "Baseten announced Baseten Router, a coding-task router in public preview through Baseten Grid."
retrieval_nugget: "Baseten announced Baseten Router, a coding-task router in public preview through Baseten Grid. In Baseten’s tests, it came within 0.8 percentage points of Opus 5.5’s pass rate while costing 72% less than using Opus for every task. The result is a promising benchmark signal, not yet proof of equivalent savings in production."
published_at: "2026-11-11"
updated_at: "2026-11-11"
record_date: "2026-11-11"
date_kind: "published_at"
topics: ["model-routing","inference"]
entities: ["Baseten","Baseten Router","Baseten Grid","Opus 5.5","GLM 5.3 Flash","DeepSWE","SWE Atlas QnA","Terminal-Bench"]
related_patterns: ["agent-economics-moves-to-completed-work"]
novelty_label: "new_fact"
what_changed: "Baseten reports Router benchmark results: it came within 0.8 points of Opus 5.5’s pass rate at 72% lower cost and is now in public preview on Baseten Grid."
prior_refs: ["https://newruntime.com/posts/baseten-launches-grid-a-gateway-and-router-for-956bed/"]
source_url: "https://www.baseten.co/blog/introducing-baseten-router"
source_urls: ["https://www.baseten.co/blog/introducing-baseten-router"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:introducing-baseten-router-a-pareto-optimal-model-router-db4bc1"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/introducing-baseten-router-a-pareto-optimal-model-router-db4bc1/","markdown":"https://newruntime.com/posts/introducing-baseten-router-a-pareto-optimal-model-router-db4bc1.md","json":"https://newruntime.com/posts/introducing-baseten-router-a-pareto-optimal-model-router-db4bc1.json"}
markdown_url: "https://newruntime.com/posts/introducing-baseten-router-a-pareto-optimal-model-router-db4bc1.md"
---

# Introducing Baseten Router: a Pareto-optimal model router for coding tasks

## Retrieval answer

Baseten announced Baseten Router, a coding-task router in public preview through Baseten Grid. In Baseten’s tests, it came within 0.8 percentage points of Opus 5.5’s pass rate while costing 72% less than using Opus for every task. The result is a promising benchmark signal, not yet proof of equivalent savings in production.

## Summary
Baseten announced Baseten Router, a coding-task router in public preview through Baseten Grid. In Baseten’s tests, it came within 0.8 percentage points of Opus 5.5’s pass rate while costing 72% less than using Opus for every task. The result is a promising benchmark signal, not yet proof of equivalent savings in production.

## What happened
Baseten’s November 4, 2026 announcement introduces Baseten Router as a system that selects a model for each coding task based on predicted performance and cost. The initial experiments route between Opus 5.5, a closed-weight model, and GLM 5.3 Flash, an open-weight coding model that Baseten says is approximately 80% cheaper than Opus across relevant workloads. Baseten says the approach can be extended to other model combinations in any harness supported by Baseten Grid. The router is part of Grid, which is in public preview; the announcement does not describe a separate price for the router.

The router predicts each model’s probability of success and cost in dollars for a task, then chooses the model with the highest predicted success minus a configurable cost penalty. That penalty controls the trade-off: changing it moves the selected operating point along a cost-performance frontier. The intended benefit is to reserve the more expensive model for tasks where its predicted improvement justifies the additional cost, rather than sending every task to the same model.

Baseten reports tests across DeepSWE 1.1, SWE Atlas QnA, and Terminal-Bench 2.1. These cover long-horizon coding, codebase question answering, and terminal tasks. Against using Opus 5.5 for every task, the router reduced cost by 72% while remaining within 0.8 percentage points of Opus’s pass rate. Baseten also compared commercial routers, including OpenRouter, FireRouter, Together, and Applied Compute. It says Baseten Router was the only one it evaluated that beat random routing by a statistically significant margin on these benchmarks at the same cost.

The company describes steps taken to make the comparison less vulnerable to noise. It corrected grader errors and broken task environments, added safeguards against cheating, and removed training tasks whose repositories appeared in the test set. Because coding agents can produce different results on repeated runs, Baseten ran each test task four times with Opus and eight times with GLM; it reports that this raised its test-set signal-to-noise ratio from 0.27 to 1.51. Its comparison simulated 10,000 random routers for each fraction of tasks routed to GLM, and defined statistical significance as outperforming 95% of those random routers at the same cost.

## What the archive adds
New Runtime’s earlier coverage framed model routers as a cost-quality trade-off ([FireRouter with Opus](https://newruntime.com/posts/introducing-firerouter-with-opus-analysis-ada3be/), October 1, 2026), and argued that they should be judged on verified work across long agent sessions ([Routers Are a New AI Primitive](https://newruntime.com/posts/routers-are-a-new-ai-primitive-13-minute-6b86f3/), October 21, 2026). Baseten’s announcement is a new benchmark result on that known story, not evidence that the production question is settled.

## Trend signal
This supports [agent economics moving to completed work](https://newruntime.com/patterns/agent-economics-moves-to-completed-work/): the relevant comparison is task success against task cost, not a token price in isolation. The benchmark uses verifier outcomes and cost per task, but the production value still depends on whether teams’ own tasks resemble the test set and whether the quality-cost trade-off holds in their workflows.

## Why now
Baseten says coding spend is growing and cheaper open-weight models are closing the capability gap. Its stated goal is to test whether a router can use those lower-cost models where appropriate while preserving frontier-level results on harder tasks. The announcement presents benchmarks as a controlled milestone before proving performance on production workloads.

## Why it matters
For a team paying frontier-model prices across a coding workflow, routing could lower spend without requiring developers to manually choose a model for every task. But the headline saving is useful only if the router preserves the outcomes that matter: accepted changes, passing tests, and reliable work on the team’s actual codebase. A small change in benchmark pass rate may also conceal differences in which tasks fail, so aggregate parity is not enough to approve a production rollout.

Baseten’s reported method offers a practical evaluation template: measure task-level cost and verifier-based success, compare the router against both fixed-model baselines and random routing, and repeat nondeterministic tasks rather than trusting one run. The announcement does not establish that its results transfer to another harness or workload. Teams should treat the 72% figure as a test-specific claim and reproduce the comparison on representative tasks before changing default routing.

## Limits and uncertainty
The reported results come from benchmarks chosen by Baseten, and the announcement is the company’s account of its own evaluation; they are not an independent replication. Baseten says it is working with design partners to specialize the router for production coding workloads and plans to share those results, so benchmark performance should not be read as a measured production saving. The initial model pair is Opus 5.5 and GLM 5.3 Flash; results for other combinations, harnesses, or routing thresholds are not established by these figures. The company’s statistical comparison addresses random routing on its test set, not every possible competing router or deployment.

## Skill to build now
Build a small, representative routing evaluation set from coding tasks your team can verify. Record model cost and pass/fail outcomes across repeated runs, then compare a fixed frontier model, a cheaper model, and a router at similar spend. This makes it possible to ask whether savings preserve the quality your own workflow needs, rather than extrapolating from a vendor benchmark.

## Reader takeaway
Baseten has published a quantified case for routing coding tasks between an expensive frontier model and a cheaper open model. Its benchmark shows a substantial cost reduction near Opus-level pass rate, but the deployment decision should wait on evidence from your own verified tasks and production conditions.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Model Routing](https://newruntime.com/topics/model-routing.md): Explore the model-routing topic hub.
- topic hub: [Inference](https://newruntime.com/topics/inference.md): Explore the inference topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)