The routing desk
Model choice is task routing, not a race for the smartest name.
You have three requests waiting: tag 20,000 support tickets, trace why a deployment plan failed, and read a photographed expense receipt. Calling the same model for all three is like sending every package by overnight courier: possible, but not necessarily wise.
In this lesson, choose a capability class, not a brand. Ask what the task actually needs: a quick text transformation, deliberate multi-step work, or the ability to perceive a document or image. Then ask what an error would cost. That last question can change the workflow even after you choose a model.
Famous models, mapped to the classes we teach
These current examples show how familiar model names fit the three capability classes.
Think in jobs, not rankings.
- Fast/cheap text models: GPT-5 nano, Claude Haiku 4.5, and Gemini 3.5 Flash-Lite are examples for high-volume, text-only, mostly single-step work such as classification, extraction from clean text, short rewrites, and routing.
- Large reasoning models: GPT-5.1, Claude Sonnet 5, and Gemini 3.1 Pro are examples to consider when a task needs several dependent steps: planning, debugging, math verification, or comparing constraints.
- Multimodal models: GPT-5.1, Claude Sonnet 5, and Gemini 3.1 Pro can also fit this class when the essential evidence includes page layout, charts, handwriting, photos, audio, or video.
These labels overlap in real products: one model can be both multimodal and strong at reasoning. The question is still which capability is doing the essential work for this task.
Fast/cheap text: the throughput lane
Choose fast text when the work is clear, text-only, repeatable, and time- or budget-sensitive.
Fast text models are the workhorses for requests that look alike thousands of times. “Label this ticket billing, login, or bug.” “Turn this meeting note into three action items.” “Extract the order number from this clean email.”
Their advantage is not that they are lesser; it is that they can answer quickly and cheaply at scale. Start here when the input is text, the rule is clear, and one good pass is enough. If a response must arrive in under two seconds or a workflow touches millions of items, latency and unit cost are requirements—not afterthoughts.
Route four work orders
Choose a lane for each order.
Text-only is necessary, but “simple enough” is the deciding test.
A customer-success team needs to assign 80,000 plain-text chat transcripts to one of six existing issue queues before the next morning. Which starting class is the best fit
Reasoning: when steps depend on steps
Reasoning depth matters when intermediate choices must be checked against each other.
Use a large reasoning model when the task is a chain, not a lookup. For example: diagnose a failing build from logs, identify the dependency conflict, propose a repair, and test whether the repair violates the deployment constraint. Each step changes how you judge the next.
These models can spend more test-time compute before they respond. That can improve work that needs planning, verification, or self-correction, but it usually brings more latency and cost. “Reasoning” does not mean “always right,” and it does not mean the system should expose private internal thinking. It means you are buying more deliberation for a task that genuinely needs it.
The over-thinking penalty
Extra deliberation can be wasteful—or even counterproductive—on a direct task.
Imagine asking a team of senior investigators to decide whether “reset password” belongs in the password queue. They can do it, but the meeting is slower and more expensive than the decision deserves.
That is the over-thinking penalty: applying deep deliberation where the task is already clear and direct. It may add tokens, latency, and opportunities to wander from a simple rule without improving the answer. The remedy is not “never use reasoning.” It is to match reasoning depth to the number and interdependence of decisions.
Which task earns deliberate reasoning?
Multimodal: when the evidence has a shape
Multimodal capability is needed when visual or other non-text evidence is essential.
Text extracted from a document can lose what the document means. On a scanned invoice, a number’s column, a handwritten correction, and a stamp may determine whether it is a total, a tax, or a note. On a chart, the visual relationship may be the evidence.
Choose multimodal when the workflow needs to perceive that evidence. This is different from image generation. The relevant question is not “Can it make a picture?” but “Can it reliably inspect the picture, page, chart, or recording I must use to decide?”
A field technician uploads a photo of a cracked equipment label. The serial number is partly handwritten and its position next to a safety symbol determines which replacement part is allowed. What capability is essential first?
A model is not a verdict
High stakes and ambiguity require an explicit human review boundary.
Model selection answers, “What can help us process this work?” It does not answer, “Who is accountable for the decision?” A system may summarize a contract, flag a medical-triage concern, or identify a possible compliance anomaly. If an error can materially harm someone, breach a duty, or carry legal or financial consequences, a qualified human must review the output and make the final call.
HITL is not a confession that the model failed. It is a workflow design: preserve evidence, show the rationale and uncertainty that a reviewer needs, route exceptions, and record the human decision.
The four-stop checklist
A repeatable routing process produces explainable choices.
Run every proposed workflow through four stops:
- Modality: Must the system inspect layout, handwriting, images, audio, or video? If yes, include multimodal perception.
- Reasoning depth: Must it plan across steps, verify math, debug, or reconcile constraints? If yes, include reasoning capability.
- Constraints: Is sub-two-second response time, high throughput, or a tight unit budget central? If yes, prefer a fast/cheap path where quality permits.
- Stakes: Could an error cause a material safety, legal, financial, or rights impact—or is the case genuinely ambiguous? If yes, design HITL review.
The checklist can return more than one answer. That is a signal to compose a workflow, not force a false single-model winner.
Trade-offs are the explanation
A good recommendation names what it gains and what it gives up.
“Use the better model” is not a decision rationale. Try this sentence instead: “Use a fast text model because this is a high-volume, clear classification task; we trade some headroom for lower cost and faster replies.”
The important trade-offs are concrete:
- Faster and cheaper paths can be a poor fit for dependent multi-step work.
- More reasoning can buy verification, but costs time and compute.
- Multimodal perception preserves visual evidence, but may cost more than text-only processing.
- Human review slows automation, but protects decisions where false confidence is expensive.
The best choice is conditional: fit the task, then state the price of that fit.
One task, several capabilities
Complex workflows often split work across classes.
Consider invoice intake. A fast text path can route clean digital invoices. A multimodal path can inspect scanned invoices with irregular tables and handwritten marks. A reasoning step can compare extracted totals with a purchase-order policy. None of these steps should silently approve a suspicious payment.
This is a pipeline choice, not a model beauty contest. Give each stage the least expensive capability that meets its requirement, then create an escalation path when evidence is unclear or stakes rise.
Arrange the model cards
Tap the cards in the sensible pipeline order.
A model card should never say “approve payment.” That is a governance boundary.
A company receives mostly clean digital invoices, plus a smaller batch of scanned invoices with handwritten changes. It must compare totals with purchase-order rules and send unusual cases to an accounts-payable specialist. Which workflow is strongest?
Leaderboards are clues, not routing rules
Benchmark standing cannot replace task-based evaluation.
Benchmarks and crowd preferences can be useful signals, but neither one knows your inputs, latency target, error tolerance, or review process. A broad score cannot tell you whether a model reads your invoice layout, follows your taxonomy, or behaves reliably on your edge cases.
Evaluate a short list on representative tasks. Measure the outcomes you actually care about: correct routing, elapsed time, cost per completed item, visual extraction accuracy, and escalation quality. Keep a small failure set. The choice is justified by the workflow’s evidence, not a universal leaderboard rank.
Case file: scanned quarterly reports
Ambiguous cases can justify more than one model class—and still demand HITL.
Your team wants to extract and validate complex financial data from scanned quarterly PDF reports, then flag potential compliance anomalies.
Two recommendations sound reasonable. One person favors a strong multimodal model because page layout, tables, and scan quality are central. Another favors a reasoning-capable model with visual tools because the compliance logic crosses many values and rules. The checklist says both concerns are real: multimodal perception for the evidence, reasoning for the logic, and human review because a compliance flag is consequential and often ambiguous.
The mature answer is an architecture: extract with visual awareness, analyze with deliberate logic, and give a compliance officer the source pages, flags, and final authority.
Make the call—then state the boundary
The learner can defend a conditional recommendation with the checklist.
Before you choose, write four brief answers: What evidence must be perceived? How many dependent decisions are there? What latency or cost ceiling matters? What happens if this is wrong, and who must decide?
Then make your recommendation in one sentence with a trade-off and a boundary: “Use ___ for ___ because ___. We accept ___; escalate ___ to a human.” This is more useful than naming a fashionable model. It gives a teammate something they can test, price, and govern.
Customer-call rehearsal
“Summarize a 30-minute recorded customer call within five minutes; flag statements that could create a contractual commitment.”
Over-automated answer: Let the model decide whether the commitment is binding. That removes the human/legal boundary where stakes and ambiguity are high.
Which statement best describes a fast/cheap text model?
Match each task to the capability that is essential first.
Your team uses a large reasoning model to label a short, unambiguous “password reset” ticket. What is the best recommendation?
Put the four decision checks in the recommended order.
For scanned quarterly PDF reports that must be checked for possible compliance anomalies, which recommendation is best?
Week 1 complete — Model family routing
Calculating your route...
You can now choose AI capability classes from task requirements, name a trade-off, and recognize when a human remains the decision-maker.