Flash or Thinking: how Fig routes every task

Every enterprise now runs on several frontier models at once, whether it admits it or not. The labs ship on a cadence of weeks. Each release is better at something, worse at something else, and priced differently from the last. A company that standardizes on one vendor is a year behind within a year. A company that lets every team pick is paying frontier prices for work a model a tenth the price would do as well.

Fig's answer, in Fig Intelligence, is to make model selection a property of the task rather than a decision a person makes per request. Two lanes, Flash and Thinking, describe what kind of work is being asked for. Beneath the lanes, a router picks the model for each task from the current frontier across several labs, and that mapping changes as the frontier does. This post describes how the router works, what it measures, how we evaluate it, and the cases where you should overrule it.

The lanes are the durable abstraction

The names of the models under the hood will be different by the time you read this. The two lanes will not, and they exist because the useful distinction in enterprise work is not which vendor but how much reasoning the task deserves.

Flash is for work that should feel instant and that the model has seen thousands of times before: drafting from company context, summarizing threads, classification and extraction, everyday edits, first-pass triage. Latency and cost dominate, and on our evaluations the best model for these tasks is rarely the largest one.

Thinking is for work where depth changes the answer: multi-step analysis, research with cited evidence, code that has to compile and pass its tests, plans that span days and tools. Thinking carries a depth dial with three notches, Faster, Normal, and Smarter, which map onto the reasoning budget the underlying model is given. Every major lab now exposes that budget as a parameter, under names like reasoning effort or thinking tokens, and the dial is our stable interface to it.

By default, nobody picks. Auto routing reads the task and chooses the lane, then the model. The lanes exist so that when someone does want to decide, the decision is about the work and not about a vendor's release notes.

What the router sees

A routing decision is made per task on signals that are available before any model runs.

• Capability required. Whether the task needs multi-step reasoning, tool use, long context, or a strict output format. A request that asks for a plan with citations across four systems is not the same as a request to rephrase a paragraph, and the difference is visible in the request.
• Modality. Text, code, images, video, audio, documents, or a combination. Modalities have different frontiers, and the best text model is often not the best model for a spreadsheet or a screenshot.
• Interaction mode. Whether a person is waiting on the answer or an agent is working in the background on a scheduled task. Latency has a different price in each case.
• Context. Recent turns, the tools already in play, and what kind of work the surrounding project is. A follow-up inside a long investigation inherits the depth of the investigation.
• Policy and budget. Which providers and models the organization has approved for this team and this class of data, and what it has decided the work is worth.

The first four signals produce two things: a lane, and a task class. The task class comes from a taxonomy we maintain over real enterprise work, organized by domain (sales, finance, engineering, support, operations), by task (draft, summarize, extract, investigate, plan, build, verify), and by modifiers that change which model wins (bounded edit, cross-system, visual, numerical, regulated). The fifth signal constrains everything that follows.

How a model earns traffic

The mistake most routing schemes make is to route on benchmarks. Public leaderboards measure the wrong distribution: they are dominated by tasks that are easy to grade, not by the tasks enterprises actually run. We route on our own evaluations of real work, with the identity of the model hidden from the grader.

For each task class we maintain an evaluation set drawn from production traffic, with the customer's permission and stripped of anything identifying, plus a set of authored cases for the failure modes that matter most: permission violations, hallucinated citations, silent truncation, and tool calls that were not asked for. Every candidate model runs the set. We record task success as judged against a rubric, a permission and safety score, latency at the median and the tail, and cost per accepted outcome, which counts the retries and the human corrections, not only the tokens.

From those measurements, three rules decide what the router may do.

1. The cheapest model that clears the bar takes the class. For each task class there is a success threshold set by the service owner. The router's default for that class is the least expensive model that meets it on the current evaluation.
2. A more expensive model takes traffic only when it is clearly better. A candidate displaces the default only when its measured uplift on that class is statistically clear, not merely newer or larger. This is the same discipline Cursor describes for its router, where a candidate needs a one-sided confidence threshold before it becomes eligible, and it is the rule that stops the router from chasing every release.
3. The mix stays inside the budget. Where several eligible models exist, the router chooses the traffic-weighted mix that delivers the largest expected gain within the cost the organization has set for that lane. Thinking's three notches are, underneath, three budgets.

Two consequences follow. A new model does not get traffic because it topped a leaderboard; it gets traffic in the classes where it wins on our set, and only there. And a model can lose traffic without anyone deciding anything, when a cheaper model closes the gap or when the model's own behavior drifts, which we watch for with the same evaluations run on a schedule.

Fallbacks and drift

Providers have outages, rate limits, and quiet regressions. The router treats each of these as a routing event rather than a failure.

When a preferred model is unavailable, the task moves to the next eligible model for its class, inside the same lane and the same policy. The user sees a result. Command Center sees which model served it. When a provider ships a silent change, the scheduled evaluation catches the drift as a drop in class success, and the model's eligibility for that class is withdrawn until it clears the bar again. The point of routing across labs is that none of this requires a meeting.

When a person should overrule the router

Auto is the right default for the large majority of work. There are three cases where pinning is correct, and the lanes are designed so that pinning is a decision about the work.

Pin Flash when the task is well understood and volume is the point: a scheduled brief, a first-pass triage of an inbox, a template applied a thousand times. You are trading a little depth for a lot of throughput, on purpose, and the evaluation for that class already told you the trade is safe.

Pin Thinking when the cost of being wrong is high and the task is unusual enough that the router has little to go on: a contract analysis, a migration plan, an incident investigation. Smarter is for the handful of tasks where minutes of extra reasoning are cheap against the decision they inform. It is not a general setting, and organizations that set it as one pay for depth they do not use.

Set a policy when the choice is not the user's to make. Administrators restrict which providers and models may serve a team or a class of data in the model hub, set defaults, and put budgets around expensive capability with usage controls so that it goes to the work that warrants it. A regulated workload can be confined to models that run inside an approved boundary. The router operates inside those limits and never outside them.

Why this is a sovereignty question

A single-vendor stack is a dependency, and the deeper it runs the less choice an institution has when the price, the policy, or the model changes. Routing across labs, with the ability to pin, restrict, and switch, keeps model choice in the institution's hands. Our research team's sovereign AI playbook names this as one of five rights an institution has to be able to exercise: the right to change the model without changing the system.

It also makes the frontier affordable to use at all. Routine work runs on models built for routine work, frontier reasoning is reserved for where it earns its price, and the bill tracks accepted outcomes rather than the ambition of whoever wrote the prompt.

What we will publish next

The numbers behind this post are the ones we run the router on, and we intend to publish them the way Cursor and others have: task success and cost per accepted outcome by class, the share of traffic each lane carries, and what changed when a new model arrived. That is a research post, and it is in the queue.

Key takeaways

• Flash and Thinking are lanes for kinds of work, not vendors. Model names rotate beneath them; the lanes and the depth dial persist.
• Routing runs on five signals visible before any model is called: capability, modality, interaction mode, context, and policy.
• A model takes a task class only when it is the cheapest that clears the bar, or measurably better than the default, inside the lane's budget.
• Outages and silent regressions are routing events: the task moves to the next eligible model and the drift shows up in scheduled evaluations.
• Pin a lane when the work is well understood or the cost of error is high; set a policy when the choice is the organization's, not the user's.

Every task is different. The right model for it is a routing decision, made on evidence, inside the limits you set.