Skip to main content

Base vs Instruct vs Reasoning Models

Introduction

Within every model family there are different flavors, and picking the wrong one quietly wastes money — or quietly gives you worse answers. Pretraining (we saw) produces a base model. But the model you chat with is an instruct model, and for genuinely hard problems there's now a third flavor: the reasoning model.

Knowing these three — and when to reach for each — is one of the most practical, cost-saving skills in this whole section. It's the difference between paying 10× for a simple task and getting a wrong answer on a hard one.

You'll learn:

  • What a base model is (and why you rarely use it directly)
  • What an instruct model is (your everyday default)
  • What a reasoning model is (think-before-answering)
  • A simple rule for which to use when — and why the line between them is blurring

Base Models — Raw Predictors

A base model is the direct output of pretraining: a pure next-token continuer (recall the pretraining lesson). It's bursting with knowledge but doesn't know it's supposed to help you — ask it a question and it may just continue the pattern rather than answer:

Prompt:  What is the capital of France?
Base:    What is the capital of Germany? What is the capital of Italy? …

You almost never use a base model directly. Its two real uses are (1) research, and (2) as a starting point for your own fine-tuning (you'll see why in the fine-tuning section). In practice, when you call "a model," you're calling one of the next two flavors. Base models are often labeled with -base in their name.

Instruct / Chat Models — the Helpful Default

An instruct (or chat) model is a base model that's gone through post-training — additional training that teaches it to follow instructions, answer helpfully, hold a conversation, and behave safely. (Exactly how that works is the next section.)

This is what you use ~95% of the time. When you call Claude, GPT, or Gemini through their normal endpoints, you're calling instruct models. They're the right default for the overwhelming majority of tasks: chat, writing, summarization, classification, extraction, RAG, and most agents. They're fast, relatively cheap, and broadly capable. Unless you have a specific reason to do otherwise, this is your model.

Reasoning Models — Think Before Answering

A reasoning model is an instruct model trained (often with reinforcement learning) to work through a problem step-by-step before giving its final answer. It generates a long internal chain of thought — extra "thinking" tokens you usually don't see — spending more compute at inference time to reason carefully. (Remember test-time compute from the scaling-laws lesson? This is it: get better answers by thinking longer, not by being bigger.)

Examples: OpenAI's o-series (o1, o3), DeepSeek-R1 (which famously matched o1 at a fraction of the cost), and the "thinking" modes of Claude and Gemini. They are dramatically better at hard, multi-step problems — competition math, intricate coding, complex logic, and deep planning.

The catch: they're slower and more expensive, because you pay for all those hidden thinking tokens. A reasoning model on a trivial task is like hiring a mathematician to add 2 + 2 — overkill that costs you time and money.

(Note: a reasoning model isn't the same as chain-of-thought prompting — just asking a plain instruct model to "think step by step." CoT prompting elicits some of this behavior; reasoning models have it trained in and do it far more thoroughly. More on CoT prompting in the prompting section.)

Three model flavors shown as cards left to right. BASE: a raw next-token predictor that just continues text; doesn't follow instructions; used almost never (research or as a fine-tuning starting point). INSTRUCT: follows instructions and chats helpfully (base plus post-training); the default for about 95 percent of tasks; fast and cheap. REASONING: thinks step-by-step before answering using extra inference compute; for hard multi-step problems like tough math and complex code; slower and more expensive. A bottom banner advises matching the flavor to the task difficulty.

Which to Use When

A simple decision guide:

FlavorReach for it when…Speed / cost
BaseAlmost never — only research or as a fine-tuning starting point
InstructYour default — chat, writing, summarization, extraction, RAG, most agentsFast, cheap
ReasoningHard, multi-step problems where correctness matters more than speed — tough math, intricate code, complex logic & planningSlow, expensive

The two mistakes to avoid: (1) using a pricey reasoning model for a simple task (you burn time and money for no benefit), and (2) expecting a plain instruct model to nail an olympiad-level problem (it'll often guess confidently and wrong). Match the model's effort to the task's difficulty.

The Line Is Blurring

In 2026, "instruct vs reasoning" is becoming less of a hard split. There are two patterns:

  • Separate reasoning models — trained specifically for it (OpenAI o-series, DeepSeek-R1, Gemini's thinking models).
  • A reasoning toggle on a general model — e.g., Claude's extended thinking, and Qwen3's hybrid thinking/non-thinking modes. Same model, but you can turn reasoning up (and even set a "thinking budget") for hard prompts and turn it off for easy ones.

So increasingly it's not three separate products but one model with a reasoning dial — pay for deep thinking only when the task needs it. Either way, the skill is the same: decide how much reasoning effort a task deserves, and spend accordingly.

Why This Matters for You

This is a direct cost-and-quality lever you'll pull constantly:

  • Defaulting everything to a reasoning model can multiply your bill and latency for tasks that didn't need it.
  • Defaulting a hard reasoning task to a plain instruct model gives confidently wrong answers.
  • The smart pattern (which you'll formalize in cost optimization): route by difficulty — instruct for the many easy requests, reasoning for the few hard ones.

Knowing the three flavors turns "which model?" from a guess into a deliberate match of model effort to task difficulty.

🧪 Try It Yourself

Match the flavor. Base, Instruct, or Reasoning for each?

  1. A customer-support chatbot. → ? 2. A hard competition-math proof. → ? 3. The starting point you'll fine-tune. → ?

1: Instruct (your ~95% default). 2: Reasoning (worth the latency/cost on genuinely hard, multi-step work). 3: Base (raw, then you align it) — though in practice you usually fine-tune from an instruct model. Matching flavor to task is a daily AI-engineering decision.

Route each incoming task to an instruct or a reasoning model — judge the difficulty yourself, then watch correctness, cost, and latency add up. Over-power an easy task and you burn money; under-power a hard one and you get a confidently-wrong answer. The skill: match model effort to task difficulty.

Mental-Model Corrections

  • "A base model is a chatbot." No — it just continues text and won't reliably follow instructions. The chatbot is the instruct model.
  • "Reasoning models are just better — use them always." No — they're slower and costlier; for simple tasks they're wasteful overkill.
  • "Reasoning is magic." It's structured chain-of-thought + more inference compute, trained in — not a different kind of intelligence.
  • "Reasoning model = chain-of-thought prompting." Related but different: CoT prompting asks an instruct model to think; a reasoning model has that trained in and does it far more thoroughly.

Key Takeaways

  • Base = raw next-token predictor (continues text; rarely used directly). Instruct = base + post-training to follow instructions and chat (your default, ~95% of tasks). Reasoning = instruct + trained to think step-by-step (for hard, multi-step problems).
  • Reasoning models use test-time compute (hidden thinking tokens) — better on tough math/code/logic, but slower & costlier.
  • Match model effort to task difficulty; route easy → instruct, hard → reasoning.
  • The split is blurring into one model with a reasoning toggle / 'thinking budget.'
  • A reasoning model ≠ chain-of-thought prompting (trained-in vs asked-for).

Next: we've kept saying "post-training turns a base model into a helpful one" — now we open that box. Section 4: Post-Training & Alignment, starting with why raw base models aren't useful and exactly how we fix that.