Which Model for Which Task: A Routing Playbook

TL;DR: Route by task: reasoning models for code and analysis, long-context models for big documents, search-native models for cited research, prose-strong models for writing, and cheap open-weight models for bulk work. The routing only pays off when all five classes sit in one subscription, so you can switch between them inside a single thread instead of buying a fourth plan for the fourth job.

Paying for one subscription that carries every major model family and then defaulting to one of them is the most expensive habit in multi-model AI. The value of the subscription is not the count in the picker, it is the two-second decision you make before each task about which model should answer. This playbook maps six common jobs to the class of model that handles them and explains the reasoning, so the choice becomes automatic rather than a menu you scroll past. Routing is the payoff of consolidation: it only exists as a choice once the families sit behind one login. It belongs in our use cases section, and it assumes you already know you can switch AI models in one conversation, because half the routing advice below depends on it. If you subscribed this week, getting started with Perspective AI covers the setup this playbook builds on.

One note on names before the table. Model version numbers move every few weeks and any page that pins a specific number goes stale faster than the advice it carries. So this page routes on families and capability classes: GPT, Claude, Gemini, Grok, DeepSeek, and the open-weight families. When you sit down at the picker, the model card is the authority. It tells you what that model is best at, who built it, its context window, and what it costs to run, all before you send anything.

How do you route a task to the right AI model?

Match the task's binding constraint to the model built for it: reasoning depth for code, context window for long documents, live retrieval for research, prose quality for writing, and price per token for bulk work. Routing this way replaces the habit of buying a specialist tool per job.

Every task has one constraint that decides the outcome. Identifying it is the whole skill, and it takes less thought than the rephrasing you would otherwise do after a mediocre answer.

The constraint that decides each job

Coding and debugging: reasoning depth first, a second opinion second

Code is the task where model choice shows up fastest, because a wrong answer compiles. Reach for a reasoning-heavy flagship and turn reasoning effort up, which is a per-request control rather than a plan tier. The extra thinking costs more credits on that one request and saves the twenty follow-up messages a shallow answer generates.

The part most people skip is the review. Once you have a fix you believe, hand the thread to a different lab's flagship and ask it to argue with the approach. Because the history travels with the switch, the reviewer reads the actual code and the actual error log rather than your summary of them. Models from different labs have genuinely different instincts about architecture and error handling, and the disagreements are where the real bugs surface. This is the workflow that a single-lab subscription structurally cannot run.

Long documents: the context window is the number that decides it

For a contract, a spec, a transcript, or a long report, capability rankings matter less than a single number on the model card. A model whose window cannot hold the document will still answer, confidently, about the portion it saw. That failure is quiet, which makes it the most dangerous one in this list. Where the document is privileged, a second constraint outranks the window entirely, and our ranking of the best AI for lawyers by confidentiality tier sorts the field on retention and training-use terms before it looks at capability at all.

So pick on the window first and quality second. Then trim what you paste, because text models meter input as well as output and a long document is most of the bill. Sending the three relevant sections instead of the whole file often halves the cost and improves the answer, since the model is no longer hunting for the relevant part. Why these windows differ so widely across the catalog, and what happens at the edges, is covered in the AI context window explainer.

Research that has to be checkable: search-native models

There are two different jobs hiding under the word research. Thinking through a problem with what a model already knows is one. Producing claims that someone else can verify is the other, and only the second needs retrieval.

For the second, use a search-native model, which answers from live web results and returns citations, or turn the web search toggle on for a general model when the question just needs current information. The distinction to hold onto: a general model with search enabled is answering and then sourcing, while a search-native model is retrieving and then answering. When the output goes into something with your name on it, prefer the second. When you just need to know whether something shipped last week, the toggle is enough and costs less.

Creative writing: prose quality is not a benchmark score

This is the one category where published scores are close to useless and your own ear is the instrument. Prose quality is a matter of taste and register, and the model that writes the best technical documentation is frequently not the one that writes the best cold email.

The efficient method is a bake-off you only run once. Take a real piece of writing you need, send the same prompt to two or three flagships side by side, and read the outputs against each other rather than in isolation. You will have a durable preference in ten minutes and can stop deliberating for months. The second habit worth keeping is the two-model pass: draft with the model whose voice you like, then hand the thread to a different one for a structural edit. Drafting and cutting are different jobs, and the model that is generous with prose is rarely the one that is ruthless with it. If you want a broader scorecard across categories before running your own test, the the family-by-family AI model comparison keeps one, and choosing which AI model to use, guide-length covers the same question from a shopping rather than a routing angle.

Quick factual lookups: the cheapest model that gets it right

Unit conversions, syntax reminders, a definition, a date, a quick reformat. These are most of the daily volume for most people and they are where a frontier reasoning model is pure waste: slower to answer and priced for work it is not doing.

Send them to a fast, inexpensive model with reasoning effort down and web search off unless the answer depends on current facts. The saving on any single lookup is trivial. The saving across a few hundred a month is the difference between an allowance that lasts and one that does not, and the cost line is visible per action so the habit is learnable rather than a matter of faith.

Cost-sensitive bulk work: the open-weight families earn their keep

Classification, extraction, tagging, reformatting, translation drafts, first-pass summaries of many similar items. Bulk work is defined by repetition, and repetition multiplies whatever per-token rate you chose.

The open-weight families in the catalog, including GLM, Qwen, Mistral, Kimi, and DeepSeek, are priced the same way as everything else, at real provider cost plus a thin margin, which puts them well under frontier flagship rates. For structured, well-specified work with a clear output format, the quality gap is often small enough to disappear entirely once you check a sample. The method that works: run twenty items on a cheap model, check them, and only escalate the categories that actually failed. Escalating everything because a handful of edge cases exist is how bulk work quietly costs frontier money. Translation drafts are the clearest case for picking an open-weight model on language coverage rather than on price alone, which is the whole argument in Qwen 3.5 vs ChatGPT. The full catalog, with the foundational and open source labels on each entry, is on the Perspective AI models page.

When to stop routing by hand

Manual routing is not a moral position. Two modes ship today: Custom, where you pick the exact model, and Auto, where the platform picks per request. Auto is a reasonable default for the broad middle of your work, where models are close enough that the choice does not change the outcome.

Keep routing by hand where the stakes or the price are lopsided. That means the two ends of this playbook: the reasoning-heavy work where capability differences are large, and the bulk work where cost differences are large. Everything between those poles is where handing the decision off costs you very little.

What routing is worth when every family sits in one subscription

The $14.99/mo Starter plan includes 250 credits and the $49.99/mo Pro plan includes 700, and both carry the identical 50+ model catalog. Since every model is metered at its real provider cost plus a thin margin, the same allowance stretches very differently depending on where you send the work. Routing is the only lever that changes that number, and it is entirely under your control.

There is a second return that does not show up on the balance. A model chosen for the constraint that actually binds gives a better answer, not just a cheaper one, and the ability to compare AI models side by side on the same prompt turns any disagreement into information rather than doubt. That is the argument for multi-model access in one sentence: one subscription is not six chatbots, it is a set of specialists you hand work between, inside a single thread. If the mechanics of that handoff are still new, start with how credits work and the cost line you will be reading before every one of these decisions.

FAQ