Instruct vs Thinking vs Base: What Model Suffixes Mean

A pattern keeps repeating in conversations with platform and infrastructure teams that are past the demo stage. Someone opens a provider's model list to pick a model and finds the same name repeated with different endings: one entry says Instruct, one says Thinking, one has no suffix at all, one says it, and a neighbor from the same family says Coder or VL. The parameter counts have become familiar vocabulary over the past two years. The suffixes have not, and they carry more weight, because two variants with identical parameter counts can be entirely different tools.

The vocabulary looks arbitrary but follows a consistent logic. Almost every suffix answers one of three questions: what stage of training the checkpoint represents, what the model is specialized for, and how the weights are being served. This post covers the first axis in depth, because it is the one that changes what the model is, and points to companion guides for the other two.

Base: a text continuer, not an assistant

Every model family starts as a base model, the checkpoint that comes out of pretraining on a large text corpus. Some vendors mark it explicitly (Qwen ships -Base variants) while others leave the base checkpoint unsuffixed and let the instruct variant carry the label, which is why "no suffix" can mean base in one family and instruct in another. A base model does one thing, which is predict the next token given the previous tokens. That single capability is the raw material all the downstream behavior is built from, but on its own it is not an assistant: there is no chat template, no concept of a user turn, and no trained disposition to answer rather than continue.

The failure mode is easy to recognize once you have seen it. Ask a base model "What are the three main causes of database connection pool exhaustion?" and a plausible completion is a fourth, fifth, and sixth question in the same style, because a list of questions is a statistically reasonable continuation of a question. The model is doing exactly what it was trained to do, on an input that assumed a different contract.

Base checkpoints are published because they are the correct starting point for fine-tuning, and because completion-style workloads genuinely want them. Fill-in-the-middle code completion is continuation by definition, which is why code assistants have historically run on base or lightly tuned checkpoints rather than chat models. If neither of those describes your workload, the base variant is less a discount option than a different interface, and pointing a chat application at it produces the failure above rather than a slightly cheaper answer.

Instruct: the application default

The instruct variant, spelled -Instruct by Meta, Qwen, and Mistral, -it in Google's Gemma line, and -chat in older releases, is the base model after instruction tuning: supervised training on prompt-and-response demonstrations, typically followed by preference optimization such as reinforcement learning from human feedback (RLHF), the recipe established by the InstructGPT paper. The result honors a chat message structure, answers the question it was asked, follows formatting requirements with reasonable fidelity, and declines some categories of request.

Two practical notes follow from this. When a hosted API lists a model with no stage suffix at all, it is almost always serving the instruct variant, since that is the version applications can actually use; the suffix is dropped, not the tuning. And the chat template that instruction tuning bakes in is model-specific, which is one of several reasons the same prompt can behave differently across families even at similar benchmark scores.

For most production workloads, the stage decision ends here. Retrieval-augmented generation (RAG), summarization, extraction, classification, customer-facing chat, and routine tool calling are all instruction-following problems, and the instruct variant is the intended tool for them. Our framework for choosing a model takes the stage decision as settled and concentrates on the harder trade-offs of task fit, cost, and context.

Thinking: paid reasoning, not a better instruct

The newest stage suffix is thinking, also labeled reasoning: Qwen's paired Thinking and Instruct releases, the line established by DeepSeek's R1, and OpenAI's o-series and gpt-oss models. A thinking model is an instruct model additionally trained to generate an internal chain of reasoning before committing to an answer. On problems where intermediate steps genuinely help, competition mathematics, multi-constraint planning, or subtle debugging, the trace buys accuracy that a single forward pass does not reach. The mechanics and the training methods behind this are covered in depth in our guide to reasoning models.

The selection question is therefore not whether thinking models are better, but whether your errors are the kind a trace fixes. The signal to look for in your own failure data is wrong answers that skipped steps: an agent that planned two moves and needed five, a calculation that went wrong in the middle, a debugging conclusion that ignored a second interacting cause. Those improve with a trace. Wrong answers that come from missing knowledge, ambiguous instructions, or bad retrieval do not, and paying for reasoning on them is pure cost.

The cost profile matters because it is invisible in the name. The reasoning trace is generated token by token like any other output, so every trace token is billed at the output rate, whether or not the provider shows it to you. The arithmetic is worth doing once. At an output price of one dollar per million tokens, a 40-token visible answer costs $0.00004; the same answer behind a 1,500-token reasoning trace costs $0.00154, a 38x multiplier on that request. At a thousand requests a day the difference is noise in absolute dollars, but at production volume, or with a per-request budget, a default-on thinking model is routinely the single largest line in the bill. Latency moves the same direction, since the whole trace is generated before the first token of the visible answer.

There is also a sharp edge worth knowing before it costs you an afternoon: reasoning traces interact badly with tight max_tokens limits. Set a small budget, and the model can spend all of it thinking and return an empty response with finish_reason: length. We hit exactly this in our own instrumentation, where a classification call to a thinking model with a 60-token cap returned empty content because the entire budget went to the trace; the fix was a larger budget plus the provider's low reasoning-effort setting, after which each verdict cost about 40 output tokens. If a thinking model appears to be returning nothing, check the finish reason before anything else.

The stage ladder is also becoming less rigid. Several model families now ship hybrid designs where reasoning is a request-time control rather than a separate checkpoint: a reasoning_effort parameter, an extended-thinking flag with a token budget, or paired Instruct and Thinking releases of the same generation. The practical consequence is that model choice and reasoning depth are becoming independent decisions, and the question shifts from which model to use toward which requests deserve paid reasoning.

The other two axes, briefly

Specialization suffixes name a different product, not a quality tier. Coder and Math variants are tuned toward one domain, VL and other vision markers accept images, Omni, Audio, and Realtime names extend that to speech and streaming interaction, Guard models classify content for safety rather than converse, and embedding and reranker models do not generate text at all. Picking a specialist for general chat, or a generalist where a specialist exists for your exact domain, are both selection mistakes, but they are mistakes on a different axis from base-versus-instruct.

Serving variants describe how the weights are run rather than what the model is: fp8, AWQ, and GGUF are quantization formats, turbo and similar labels are providers' speed-optimized deployments, and distill marks a smaller model trained to imitate a larger one. These affect accuracy and cost in ways the original benchmark numbers may not describe, and they deserve their own decision process, which our guide to quantization, LoRA, and distillation labels provides.

The markers outside the three axes

Two further suffix families appear constantly in provider lists and belong to neither the stage, the specialization, nor the serving axis.

Size-tier names are how closed-model vendors spell the size axis when they do not publish parameter counts: mini, nano, flash, and lite mark the small end, Pro, Max, and Ultra the large end, and names like Air sit between. These are relative markers within one family, not comparable across vendors, so one vendor's small tier can outperform another's mid tier and the name alone cannot tell you. Open-weight names encode the same information directly instead: 122B-A10B reads as 122 billion total parameters with 10 billion active per token (the mixture-of-experts notation), and occasional context markers such as -1M advertise the window.

Lifecycle markers describe how stable the endpoint is rather than anything about the model: preview, exp, and beta flag releases that can change or disappear under you, dated snapshots such as -2507 pin one immutable version, and a bare or latest alias is a moving pointer the vendor re-aims silently. For anything in production the dated snapshot is the safer reference, since pinning an alias means the model you evaluated and the model you are serving can quietly diverge.

Reading five real names

The fastest way to make the axes stick is to decode names you have actually scrolled past.

gemma-4-31b-it. Family and generation, 31 billion parameters, and it for instruction-tuned: Google's spelling of instruct. This is the variant you point applications at, and the reason a bare gemma-4-31b behaves so strangely in a chat harness is that the two-letter difference is the entire chat interface.

Llama-3.1-70B versus Llama-3.1-70B-Instruct. Meta leaves the base checkpoint unsuffixed, so here the absence of a suffix is the warning. Teams have benchmarked the bare name, gotten rambling continuations, and concluded the model is weak, when the model under test was never an assistant to begin with.

DeepSeek-R1-Distill-Qwen-32B. The trap in this one catches experienced engineers: it reads as R1, but it is a 32-billion-parameter Qwen model fine-tuned on R1's reasoning traces. It thinks like R1 in style, at a distilled model's capability ceiling, at a fraction of the size. Whether that trade is excellent or disqualifying depends entirely on your workload, and the name only helps if you read every segment.

gpt-4o-mini and gemini-2.5-flash-preview. Closed-vendor names carry a size tier (mini, flash) instead of a parameter count, and sometimes a lifecycle marker: preview means the endpoint can change or vanish. Neither name states a training stage because hosted APIs serve the instruction-tuned variant by default; the stage axis is implicit.

Qwen3.5-122B-A10B-Instruct-fp8. All the axes at once: family and generation, 122 billion total parameters with 10 billion active per token, instruction-tuned, served at fp8 precision. Reading it as four independent facts takes a few seconds; reading it as one opaque string is how the wrong variant gets deployed.

How to decide: three questions

For choosing between the stages, three questions resolve nearly every case, and they are worth asking in order because each one only matters if the previous answer says so.

The first question separates interfaces: continuation workloads (fill-in-the-middle completion, or providing the starting point for your own fine-tune) want base, and everything that answers a request wants a tuned variant. The second separates cost profiles: if your failure modes are skipped-step failures, thinking earns its trace; if they are knowledge, retrieval, or instruction failures, it does not. The third question handles the honest middle case, where most traffic is routine and a minority genuinely needs reasoning. That split is exactly what hybrid effort controls exist for, and at higher volume it is the case for routing by request rather than picking one model for everything, which the closing sections of this post return to.

Which one to use, by workload

The table below is the short version of the stage decision. It assumes the hosted-API case; self-hosting changes the economics but not the interface logic.

Does any of this matter with GPT, Gemini, and Claude?

A reasonable objection comes up whenever this taxonomy is presented: the frontier closed models are strong enough generalists that a single endpoint handles chat, extraction, code, and analysis competently, so why study training stages at all? Two answers, one about the names and one about the economics.

The names first: the closed vendors ship the same axes under their own spellings, so the taxonomy does not disappear behind the API, it just gets renamed. Reasoning is a separate model line or a request-time control (OpenAI's o-series and reasoning effort settings, Anthropic's extended thinking, Google's thinking variants of Gemini). Size tiers stand in for parameter counts (mini, flash, pro). Dated snapshots against a latest alias are the lifecycle axis, and the deprecation schedules that retire those snapshots are a fact of production life with every closed vendor. An engineer who has internalized the axes reads a closed vendor's model page in seconds; one who has not tends to discover the reasoning-versus-standard distinction through a surprising invoice.

The economics second: "capable of any task" and "the right tool for every request" are different claims. Frontier models are the strongest generalists available, and for the hardest tail of a workload they are frequently the only defensible choice. But at integration volume, most traffic in a real application is not the hardest tail. Classification, routine extraction, templated drafting, and simple lookups sit well within the competence of models priced an order of magnitude lower, and paying frontier rates for them buys latency and bills, not quality. For enterprise workloads the calculus adds non-model factors that deserve their own evaluation: data-handling and retention terms, regional availability, rate-limit ceilings against your peak traffic, and how much rides on a single vendor's deprecation calendar. None of those argue against using frontier models; they argue against using exactly one model for everything by default.

One model for everything, or a model per task?

Which brings the question underneath this whole post into the open. Suppose you are integrating an assistant into a product: the workload is mostly short support-style chat, a steady stream of RAG answers over your docs, a classification step on every ticket, and an occasional genuinely hard multi-step diagnosis. Pick one model for all of it and every choice is a compromise in some direction: a frontier generalist handles the hard tail and overpays tenfold on the classification volume, a cheap instruct model wins the volume economics and fumbles the diagnoses, and a thinking model as default bills reasoning traces on requests that never needed them.

Assigning models per task is the answer the taxonomy itself suggests, and the stage ladder is the first cut: instruct for the chat, RAG, and classification volume, thinking (or a hybrid with effort raised) for the diagnosis tail. The practical difficulty is not choosing once, it is that the choice does not stay made. Catalogs move weekly, prices shift, variants appear, and the per-task assignment you evaluated in one quarter quietly stops being the right one the next. That maintenance burden is the honest cost of the per-task approach, and it is the problem model routing exists to automate: classify each request, apply quality evidence per task, and let the assignment update as the catalog does. Whether you maintain the mapping by hand or route automatically, the mapping is where the savings live; comparing candidates side by side on the tasks you actually run is the place to start.

The mistakes that repeat

Five failure patterns account for most of the confusion this vocabulary causes in practice.

1. A chat application pointed at a base checkpoint. The output looks broken in a distinctive way (continuations, question lists, drift) and the fix is the instruct variant, not a bigger model.
2. Thinking as the default because it benchmarks highest. The benchmark wins come from workloads with skipped-step failures. On extraction, classification, and routine chat, the same model bills a trace and returns the answer the instruct variant would have given.
3. A tight max_tokens on a thinking model. The budget disappears into the trace and the visible answer arrives empty with finish_reason: length. Raise the budget or lower the effort setting before concluding the model is broken.
4. Evaluating one variant and deploying another. The team tests -Instruct and ships -turbo, or tests a dated snapshot and pins latest. The serving variant and the lifecycle marker are part of the model's identity, and a change in either is a change in what you measured.
5. Reading a distill name as its teacher. A -Distill- model imitates its teacher's style at its own, smaller capability ceiling. Budgeting quality expectations off the teacher's benchmarks is a category error the name openly warns about.

Two habits keep all of this useful as naming fashions change. Read a model name as three independent axes rather than one string, and treat any stage suffix you do not recognize as a question to answer before deployment rather than after. While a quality difference shows up as somewhat worse output, an interface mismatch shows up as output that was never going to be right, and the suffix is where the interface is declared. Every variant in our model catalog carries its stage and serving labels for exactly this reason, so the comparison you make is between tools of the same kind.