Shift-1, a SOTA coding router

Today we’re releasing Shift-1, a frontier model router trained on AC2 for coding and knowledge work. Try Shift-1⌝.

Most routers choose one model at the start of a task. Shift-1 makes that decision for each request, adapting as your work unfolds. On our internal coding usage, it cuts Codex spend by 55% compared with GPT-6-Astra and Claude Code spend by 24% compared with Opus 5.5, with no discernible drop in intelligence.

We’re also introducing AC2 Routers⌝, infrastructure for any team to train, serve, and improve their own router models for their workloads.

Our goal with Shift-1

Model routers have become popular because they promise to dramatically cut inference costs by using cheaper models for routine work and reserving more capable models for harder problems.

However, most routers available today reduce costs at a significant hit to intelligence. For our and our customers' work, that was not a tradeoff we were willing to make.

Our goal for Shift-1 was to dramatically reduce cost without sacrificing intelligence. Shift-1 is indistinguishable from using GPT-6-Astra or Claude Opus 5.5 at up to half the price.

How we built Shift-1

Most smart routers classify at the task (user message) level, not the request level. Task-level routing can perform well on benchmarks but fail to be useful in products like Codex and Claude Code where individual tasks are multifaceted and sessions can go on for hundreds of turns.

For the past several months, we’ve been collaborating with the NVIDIA NeMo Switchyard⌝ team on router research. That work shaped several design decisions for Shift-1. In order to build a smart, cheap router that was useful in our day-to-day work, we built Shift-1 with the following properties:

1. Drop in replacement model endpoint: Shift-1 is a single model replacement, which guarantees that it works well in situations where we don’t control the harness. Harness-level routing is also valuable and you can use it in conjunction with Shift-1.
2. Per-request router: per-task routing is common in model routers, but has severe limitations for agentic use cases, especially long-horizon tasks. As we wrote⌝ about in collaboration with NVIDIA, assessing difficulty is often challenging at the start of a turn. Tasks may appear easy at first but turn out to be challenging as the agent makes more progress.
3. Cheap and performant policy model: we seek to train small router policy models that do not sacrifice latency and are cheap to serve.
4. Cost-aware: our routing system must consider costs associated with switching models as a result of routing decisions. Routers that do not consider cache switch costs can cost even more money than the most expensive target model.

We’re excited to collaborate with Applied Compute on Shift-1 and AC2 Routers, demonstrating how custom routing models can work with NeMo Switchyard to help agents use the right model at the right time, balancing quality, cost, and enterprise needs.

Ian Cairns

Director of Product Management, NVIDIA

Powered by AC2 Routers

Shift-1 is built and served on AC2 Routers, our newly released infrastructure to train, serve, monitor, and improve model routers. At the core of every router is a router policy, which takes a request and a set of eligible models and picks the best one. Shift-1's policy is a custom 4B parameter decision model powered by AC2 decision model training (learn more⌝).

AC2 Routers naturally fit in with AC2’s core features of training and inference. While Shift-1 routes to closed source OpenAI and Anthropic models, it could just as easily route to post-trained model families like Kimi and Nemotron. Together, AC2 training, routers, and inference push the frontier for better, faster, cheaper models you own.

Shift-1 Results

On thousands of turns of Applied Compute's own internal coding, Shift-1 reduces Codex spend by 55% versus GPT-6-Astra by routing between Astra and GPT-6.1-Sol. In Claude Code, it reduces spend by 24% versus Opus 5.5. We focus our evals on production traffic using user satisfaction. This metric is created with a calibrated LLM judge asked if there was a correction, a re-ask, or any indication of frustration with the response. We assess this metric on All-Astra/All-Opus traces and router traces in live internal A/B testing.

Additionally, on a small subset of production turns (n=117), we created evals on user-turn replays as follows:

• Rubrics: We use an LLM to identify a list of requirements from the original trace, given full context on the agent’s actions and developer reaction.
• All-Astra Passing Rubrics: From there, we inspect an additional 3 All-Astra rollouts and add items that All-Astra shadow rollouts agree on. This rubric generation procedure produces statistically significant differences in scores for Sol and Astra.

Below we show the pareto frontier of these eval tasks using Shift-1 as well as OpenRouter Jev (Astra/Sol) and OpenRouter Auto (Astra/Sol, always choses Astra). Unfortunately, we were unable to benchmark Fireworks FireRouter due to lack of ZDR.

Below is an example of one of these sample rubrics:

Much of Shift-1’s ability to maintain frontier intelligence is due to it properly escalating to Astra on the hardest tasks. In comparison, we were disappointed to find that FireRouter (Opus/GLM-5.3/GLM-5.3 Flash) and OpenRouter Auto (Astra/Sol), which route once per task, barely adjust as the difficulty increases. This is one of many interesting results we had while building and evaluating Shift-1. Below we show this observation on tasks across SWE-Bench Verified.

Try Shift-1 today

Shift-1 is available today to try at shift.ac⌝. Install it in your Codex or Claude code to immediately cut your own inference costs in half.

Training and deploying your own router is available via AC2 in private beta. Reach out⌝ to onboard and learn more.