TL;DR — AI reasoning models in 2026: OpenAI o3 (87.5% ARC-AGI, 91.6% AIME, $15/$60 per 1M), DeepSeek R1 (open-source, 79.8% AIME, $0.55/$2.19 per 1M, 20-30x cheaper), Claude extended thinking (best practical reasoning, 200K context), Gemini 2.5 Thinking (92.0% AIME, 1M context). Test-time compute scaling: 3 scaling laws. Hidden reasoning tokens: 1.5-4x token multiplier. 3-5x latency increase. o3 high-compute: 57M tokens/question, 14 min runtime. DeepSeek R1: MoE 671B params, 37B active. When to use: math, coding, legal, multi-step. When NOT: chat, drafting, simple recall. Prompting: describe problem clearly, trust the model, don't say 'think step by step'.

AI Reasoning Models Explained in 2026: o3, DeepSeek R1, Claude, Gemini — How They Think

Instead of making the model bigger, you let the model think for longer. The model is trained to generate a long internal chain of intermediate reasoning — exploring solution strategies, checking partial answers, backing up when something looks wrong — and only after this chain is done does it produce the final response. This is test-time compute scaling, and it changed what is possible on hard analytical work.

Key Statistics

Model Comparison

Sources: zylos (2026), ailog (2026), iabrief (2026), humai (2026), rruc (2026).

The Three Scaling Laws

Source: zylos (2026), prompt20 (2026).

Reasoning Model Architecture

Source: prompt20 (2026), zylos (2026), pr-peri (2026).

When to Use vs Not Use

Source: aiexpert (2026), jamesm (2026).

Cost Comparison

Sources: iabrief (2026), humai (2026), rruc (2026).

Prompting Guide

Source: aiexpert (2026), prompt20 (2026).

Implementation Guide

Best Practices

1. Use the right model for the task — don't use o3 for a question GPT-5 can answer. 73% of developers use reasoning models only for complex tasks requiring >90% accuracy (rruc 2026).

2. Don't say 'think step by step' — reasoning models already do this internally. The phrase is redundant and can interfere with the model's internal reasoning process (aiexpert 2026).

3. Set thinking budgets — use reasoning_effort (OpenAI), budget_tokens (Claude), or max_thinking_tokens (self-hosted) to control costs. Don't let the model think indefinitely (prompt20 2026).

4. Use distilled variants — R1-Distilled costs $9 vs $40 for full R1 vs $75 for o1. 78% cost reduction for negligible performance drop (rruc 2026).

5. Route by complexity — multi-model routing (fast for simple, reasoning for complex) reduces costs by 60-80%. Don't use reasoning models for 100% of queries (jamesm 2026).

6. Monitor reasoning tokens — track them separately from output tokens. Set alerts when reasoning token usage exceeds thresholds. 1.5-4x token multiplier is the hidden cost (rruc 2026).

7. Benchmark on your tasks — published benchmarks (AIME, GPQA, SWE-Bench) are useful for comparison, but your actual task distribution is what matters. Reasoning models may perform differently on your specific tasks (pr-peri 2026).

8. Use the useful rule — 'If you wouldn't pay an analyst to spend 20 minutes on the task, don't use a reasoning model. If you would, do.' (aiexpert 2026).

For related topics, see our chain of thought prompting, AI agent cost at scale, AI agent testing, small language models, and AI model distillation guides.

FAQ

What is test-time compute scaling?

Test-time compute scaling is the mechanism that makes reasoning models work. Instead of making the model bigger (pre-training scaling) or fine-tuning it more (post-training scaling), you let the model spend more computational resources at inference time — when it's answering a question — to improve accuracy. How it works: (1) Standard models process every query with the same fixed forward pass. Whether you ask 'what is 2+2' or 'prove the Riemann hypothesis,' the model spends the same amount of compute. This is inefficient — easy problems get too much compute and hard problems get too little. (2) Reasoning models allocate compute proportional to problem difficulty. A simple factual question gets minimal thinking tokens. A graduate-level physics problem gets thousands of internal reasoning tokens. This adaptive computation is why reasoning models are worth their cost: they don't waste resources on easy tasks but bring enormous capability to hard ones. (3) The scaling is predictable. Snell et al. (2024) established empirically that, for many tasks, more thinking tokens at inference time produce better answers, with returns that scale roughly logarithmically with compute. Harder problems benefit more from longer thinking. (4) The scaling is non-linear. On some hard benchmarks (FrontierMath, ARC-AGI), enormous test-time compute budgets (millions of tokens per problem, vast best-of-N sampling) can solve problems unreachable with normal budgets. o3's high-compute setting scored 87.5% on ARC-AGI — a benchmark where standard LLMs score 0%. The three scaling laws: (1) Pre-training scaling — the traditional 'bigger model, more data' approach. Still the most expensive. Diminishing returns in 2026. (2) Post-training optimization — fine-tuning, RLHF, and distillation to specialize capable base models. Moderate cost. (3) Test-time compute scaling — letting models 'think longer' at inference. Variable cost (pay per think). 2026 focus: 'efficiency scaling' — achieving $1M-compute results for $1. Why it matters: (1) New capability axis — test-time compute unlocked capabilities that larger models fundamentally couldn't achieve, regardless of parameter count. o3 with test-time compute solves problems GPT-4-scale models can't. (2) Smaller models can compete — DeepSeek R1 demonstrated that reasoning performance comparable to o1 can be achieved with a model whose API pricing was ~5% of o1's. The reasoning capability is not locked behind frontier-scale training. (3) Dynamic trade-off — you can trade latency for accuracy dynamically. Easy problems get fast responses. Hard problems get slow, accurate responses. This is something standard models cannot do. (4) Cost control — you control how much compute to spend. Use low reasoning_effort for simpler problems, high for complex ones. The cost structure: in the high-compute regime, o3 averages 57 million tokens per question and ~14 minutes of runtime for the hardest problems. The cost-per-problem at those budgets is in the hundreds of dollars. In the low-compute regime, o3-mini responds in 6-27 seconds at $4.40 per 1M output tokens. The economics of inference now look more like the economics of training — you're paying for compute time, not just text generation. The category split: (1) Synchronous reasoning — the model thinks for seconds-to-minutes and returns an answer. This is what most people use. (2) Agentic reasoning — the model thinks across many tool calls and external interactions over hours. This is the frontier of agent workflows. The key: 'OpenAI's o1 and o3 demonstrated that test-time compute could achieve results that GPT-4-scale models fundamentally could not, regardless of parameter count.' Test-time compute is the third scaling law and the most important innovation in AI since the original transformer. It trades time and tokens for accuracy, and the curves are favorable — more thinking keeps improving the score for far longer than expected (zylos 2026, prompt20 2026, jamesm 2026, pr-peri 2026)."
- question: "How does DeepSeek R1 compare to OpenAI o3 on cost and performance?"
answer: "DeepSeek R1 and OpenAI o3 are the two most discussed reasoning models in 2026, and they represent fundamentally different philosophies. DeepSeek R1: open-source, low-cost, observable reasoning. OpenAI o3: proprietary, frontier performance, hidden reasoning. Cost comparison: (1) DeepSeek R1 API — $0.55 per 1M input tokens, $2.19 per 1M output tokens. (2) OpenAI o3 API — $15 per 1M input tokens, $60 per 1M output tokens. (3) DeepSeek R1 is approximately 20-30x cheaper than o3 on input tokens and ~27x cheaper on output tokens. (4) DeepSeek R1 self-hosted — GPU + electricity cost only. Zero per-token cost. (5) R1-Distilled variants — $9 per 1M output tokens. 78% cost reduction vs full R1, negligible performance drop. (6) o3-mini — $1.10 input / $4.40 output. More affordable but still 2x R1 on output. Performance comparison: (1) AIME 2025 — o3 88.9%, DeepSeek R1 79.8%. o3 wins by ~9 points. (2) ARC-AGI — o3 87.5% (high compute), nearly 3x o1. DeepSeek R1 not directly comparable on this benchmark. (3) GPQA Diamond — o3 91.9%. DeepSeek R1 comparable but slightly lower. (4) SWE-Bench Verified — o3 71.7%, R1 49.2%. o3 wins by ~22 points on real GitHub issue solving. (5) Codeforces — o3-mini rating 2,029, R1 rating 1,820. o3 wins. (6) AIME 2024 — o3-mini (high) 83.6%, R1 79.8%. o3-mini wins by ~4 points. (7) o3-mini is 3-6x faster than R1. Coding task: o3-mini 27s, R1 105s. Logic puzzle: o3-mini 6s, R1 80s. Key differences: (1) Open source — R1 is MIT-licensed, fully open weights. You can self-host, fine-tune, modify. o3 is proprietary, API only. (2) Reasoning visibility — R1 shares full chain of thought in tags. Observable, debuggable, educational. o3 hides reasoning tokens (private chain of thought). You see only a summary. (3) Architecture — R1 uses Mixture-of-Experts (MoE): 671B total parameters, 37B active per token. This keeps computational costs relatively low. o3's architecture is not publicly known. (4) Distilled variants — R1 has distilled variants: R1-Distill-32B runs on RTX 4090, R1-Distill-7B runs on a laptop. o3 has no self-hostable variants. (5) Tool use — o3 has more mature tool use: parallel calls, code interpreter, browser integration. R1's function calls work but with lower reliability. (6) Context window — R1 128K, o3 varies, Claude 200K. (7) Ecosystem — o3 has full OpenAI ecosystem: Assistants API, GPTs, ready integrations, SOC2 compliance. R1 has academic community adoption: many forks and fine-tunes. (8) Censorship — R1 has ideological censorship on politically sensitive China topics. o3 has no such censorship. (9) Latency — o3-mini is consistently 3-6x faster than R1. For iterative work, this matters enormously. When to choose DeepSeek R1: (1) Cost-sensitive production workloads — 20-30x cheaper. At high volume, this saves thousands per month. (2) Self-hosting requirements — run on your own infrastructure, no API dependency. (3) Open-source requirements — need to audit, modify, or fine-tune the model. (4) Observable reasoning — need to see the full chain of thought for debugging or compliance. (5) Academic research — need reproducible, modifiable reasoning model. (6) Budget deployment — R1-Distill-7B runs on a laptop. When to choose OpenAI o3: (1) Frontier performance — need the highest possible accuracy on competition math, coding, science. (2) Speed matters — o3-mini is 3-6x faster. For iterative work, this is critical. (3) Enterprise compliance — SOC2, enterprise audit, corporate approval. (4) Mature tool use — parallel calls, code interpreter, browser. (5) OpenAI ecosystem — Assistants API, GPTs, ready integrations. (6) No censorship concerns — need uncensored responses on all topics. The key: 'DeepSeek R1 is 4x cheaper than o3 with comparable reasoning quality on many tasks — making it the cost-efficient choice for production workloads.' For frontier performance, o3. For cost-efficient production, R1. For the best of both worlds, o3-mini for speed-sensitive tasks and R1 for cost-sensitive tasks (humai 2026, iabrief 2026, ailog 2026)."
- question: "Can I run reasoning models locally?"
answer: "Yes, you can run reasoning models locally in 2026, thanks to the open-weights reasoning ecosystem led by DeepSeek R1 and its distilled variants. What's available for local deployment: (1) DeepSeek R1 (full) — the complete model with 671B parameters (MoE, 37B active). Requires significant hardware: multiple high-end GPUs (e.g., 8x H100 or 8x A100 80GB). Suitable for data center deployment, not consumer hardware. (2) R1-Distill-32B — distilled into a 32B parameter model. Runs on a single RTX 4090 (24GB VRAM) or equivalent. Maintains strong reasoning capability at a fraction of the full model's size. This is the sweet spot for local reasoning: consumer GPU, strong performance. (3) R1-Distill-7B — distilled into a 7B parameter model. Runs on a laptop with 8GB+ VRAM. Reasoning capability is reduced but still useful for simpler multi-step problems. (4) R1-Distill-14B — middle ground between 7B and 32B. Runs on GPUs with 16GB+ VRAM. (5) QwQ (Qwen) — Qwen's reasoning model series. Open weights, various sizes. (6) Sky-T1 — academic reasoning model, open weights. (7) s1 line — academic models from the s1 paper, open weights. (8) Marco-o1 — academic reasoning model, open weights. How to run locally: (1) vLLM — the most popular serving framework for LLMs. Supports DeepSeek R1 and distilled variants. Use max_thinking_tokens parameter to control reasoning length. Supports tensor parallelism for multi-GPU deployment. (2) SGLang — alternative serving framework. Uses stop-token logic on the closing tag to control reasoning. Supports continuous batching for higher throughput. (3) Ollama — simplest local deployment. Download and run with a single command. Supports R1-Distill variants. Best for development and testing. (4) LM Studio — GUI-based local deployment. Supports R1-Distill variants. Good for non-technical users. (5) llama.cpp — C++ implementation for maximum efficiency. Supports GGUF quantized versions of R1-Distill. Runs on CPU or GPU. Hardware requirements: (1) R1-Distill-7B — 8GB+ VRAM (RTX 4060, MacBook Pro M2+). (2) R1-Distill-14B — 16GB+ VRAM (RTX 4080, A4000). (3) R1-Distill-32B — 24GB+ VRAM (RTX 4090, A5000). (4) DeepSeek R1 (full) — 8x H100 or 8x A100 80GB (data center). (5) With quantization (GGUF, AWQ, GPTQ) — reduce VRAM requirements by 2-4x at a small cost in accuracy. Advantages of local deployment: (1) Zero per-token cost — you pay for hardware and electricity, not per query. At high volume, this is dramatically cheaper than API. (2) No rate limits — self-hosted models have no API rate limits. Process as many queries as your hardware supports. (3) Privacy — data never leaves your infrastructure. Critical for healthcare, finance, legal. (4) Customization — fine-tune the model on your domain. Modify the reasoning process. (5) No vendor dependency — no API downtime, no price changes, no deprecations. (6) Observable reasoning — R1's tags are fully visible. Debug and improve prompts. (7) Latency control — no network round-trip. Lower latency for local workloads. Disadvantages of local deployment: (1) Hardware cost — RTX 4090 is ~$1,600. 8x H100 is ~$200,000+. (2) Maintenance — you manage updates, security patches, model upgrades. (3) No auto-scaling — you provision for peak load. Idle hardware costs money. (4) Smaller models — distilled variants are less capable than full R1 or o3. (5) Slower than API — consumer GPUs are slower than data center GPUs. R1-Distill-32B on RTX 4090 is slower than R1 via API. (6) No built-in tool use — API providers offer tool use, code interpreter, browser. Self-hosted models need custom integration. (7) Quantization cost — quantized models (GGUF, AWQ) lose some accuracy. The key: 'R1-Distill-32B runs on RTX 4090; R1-Distill-7B runs on a laptop.' Local reasoning is accessible in 2026. For most developers, R1-Distill-32B on a single RTX 4090 is the sweet spot — strong reasoning capability, consumer hardware, zero per-token cost. For production, use vLLM or SGLang for efficient serving. For development, use Ollama for simplicity (humai 2026, iabrief 2026, prompt20 2026)."
- question: "What is DeepSeek R1-Zero and why is it significant?"
answer: "DeepSeek R1-Zero is the version of DeepSeek's reasoning model that was trained using pure reinforcement learning (RL) without any supervised fine-tuning (SFT) on human-labeled reasoning trajectories. It is significant because it proved that reasoning capabilities can emerge from pure RL alone — a fundamental breakthrough in AI research. What happened: (1) Starting point — DeepSeek started with a base language model (DeepSeek-V3, a 671B parameter MoE model). (2) Pure RL training — instead of first fine-tuning on human-labeled chain-of-thought examples (the standard approach), they applied reinforcement learning directly to the base model. The RL used verifiable rewards: the model was given problems with verifiable answers (math, code, logic) and rewarded for correct final answers. (3) Spontaneous emergence — without any human-labeled reasoning examples, the model spontaneously developed: (a) Chain-of-thought reasoning — breaking problems into steps. (b) Self-reflection and verification — checking its own work. (c) Strategy exploration and adaptation — trying different approaches. (d) Multi-step problem decomposition — breaking complex problems into manageable parts. (4) The model naturally learned to generate longer responses incorporating verification, reflection, and alternative approach exploration — all without human-labeled reasoning trajectories. Why this is significant: (1) Reasoning is not locked behind human data — before R1-Zero, the assumption was that reasoning models needed human-labeled chain-of-thought examples for supervised fine-tuning. R1-Zero proved that reasoning can emerge from RL alone, using only verifiable rewards. (2) Lower training cost — without the need for human-labeled reasoning data (which is expensive to create), training costs are lower. DeepSeek R1 was trained at a fraction of the cost of OpenAI's o1. (3) Open-source implications — if reasoning can emerge from pure RL, then any team with enough compute can train a reasoning model. This democratizes reasoning model development. (4) Scientific insight — R1-Zero provides evidence that reasoning is an emergent property of RL with verifiable rewards, not something that needs to be explicitly taught. This has implications for AI safety (reasoning can be elicited, not just trained) and for understanding how LLMs reason. (5) The published recipe — DeepSeek published the RL-from-verifiable-rewards recipe, allowing others to replicate and build on it. This led to a wave of open-weights reasoning models: QwQ, R1 distillations, Sky-T1, s1, Marco-o1. From R1-Zero to R1: R1-Zero demonstrated that pure RL works, but the model had some issues: lower readability, language mixing (Chinese and English), and less coherent reasoning traces. DeepSeek R1 (the final version) added a small amount of supervised fine-tuning before RL to address these issues, resulting in a more polished model while maintaining the core RL-based reasoning capability. The R1 recipe: (1) Start with a capable base model (DeepSeek-V3). (2) Optional: small amount of SFT on cold-start reasoning data (for R1; skipped for R1-Zero). (3) Apply RL with verifiable rewards (math, code, logic problems with checkable answers). (4) Model learns to generate reasoning traces through reward optimization. (5) Reasoning capabilities emerge: CoT, self-reflection, verification, strategy exploration. (6) Distill into smaller models (R1-Distill-7B, 14B, 32B) for wider accessibility. The key: 'DeepSeek-R1 represents a fundamental breakthrough: reasoning capabilities can emerge from pure reinforcement learning without supervised fine-tuning as a preliminary step.' R1-Zero proved that the reasoning capability is not locked behind human-labeled data or frontier-scale training. It can be elicited through RL with verifiable rewards. This finding democratized reasoning model development and led to the open-weights reasoning ecosystem of 2026 (zylos 2026, prompt20 2026, pr-peri 2026)."
- question: "What are the benchmarks for evaluating reasoning models?"
answer: "Evaluating reasoning models requires different benchmarks than standard LLMs. Standard benchmarks (MMLU, HellaSwag, TriviaQA) measure knowledge and simple reasoning. Reasoning benchmarks measure multi-step problem solving, mathematical reasoning, code generation, and abstract reasoning. The benchmarks the field watches for reasoning in 2026: (1) AIME (American Invitational Mathematics Examination) — the canonical mid-difficulty math benchmark for reasoning models. Tests competition-level math that challenges even gifted high school students. Scores: o3 88.9%, Gemini 2.5 Pro 92.0%, Grok 3 ~93%, DeepSeek R1 79.8%, o3-mini 83.6%. Standard LLMs score below 10%. (2) FrontierMath (Glazer et al., 2024) — for the upper bound of mathematical reasoning. Tests problems at the frontier of current mathematics. Extremely difficult — even the best reasoning models score low. Used to measure the ceiling of reasoning capability. (3) GPQA-Diamond (Rein et al., 2023) — graduate-level science questions. Tests reasoning at the level of a PhD candidate in physics, chemistry, biology. Scores: o3 91.9%. This is the benchmark for scientific reasoning. (4) LiveCodeBench (Jain et al., 2024) — for code, with a rolling window. Tests competitive programming and real-world coding. Uses a rolling window to prevent contamination from training data. Scores: Gemini 2.5 Pro 77.1%. (5) ARC-AGI series — for abstract reasoning. Designed to be hard for current LLMs. Tests pattern recognition, rule induction, and abstract reasoning. Scores: o3 87.5% (high compute), nearly 3x o1. Standard LLMs score 0%. This is where reasoning models show categorical, not incremental, improvement. (6) SWE-Bench Verified — tests ability to solve real GitHub issues. Measures practical coding reasoning, not competition coding. Scores: o3 71.7%, R1 49.2%, Claude leads on practical debugging. (7) Codeforces — competitive programming rating. o3-mini achieved rating 2,029, R1 1,820. (8) MATH-500 — 500 math problems ranging from easy to olympiad-level. Standard benchmark for math reasoning. (9) Humanity's Last Exam — cross-domain hard items. Tests reasoning across multiple domains at the frontier of human knowledge. (10) MMMU — multi-modal reasoning. Tests reasoning with images, diagrams, and text. o3 set SOTA on MMMU. Why these benchmarks matter: (1) Contamination resistance — benchmarks like LiveCodeBench use rolling windows to prevent the model from having seen the problems during training. This is critical because reasoning models are trained on large datasets that may include benchmark problems. (2) Verifiable answers — math and code problems have verifiable answers. You can check if the answer is correct objectively, without subjective judgment. This makes them ideal for RL training (verifiable rewards) and for evaluation. (3) Difficulty gradient — AIME is mid-difficulty, FrontierMath is upper bound, GPQA is graduate-level. This gradient shows where the model's capability ceiling is. (4) Categorical improvement — on some benchmarks (ARC-AGI), the improvement from reasoning models is not incremental but categorical. Standard LLMs score 0%, o3 scores 87.5%. This is a qualitative difference, not a quantitative one. (5) Practical vs competition — SWE-Bench tests practical coding (real GitHub issues) while Codeforces tests competition coding. Both are important but measure different things. (6) Cost-adjusted evaluation — a system that scores well on accuracy but requires 26,000 tokens per query is not production-viable. Evaluate with token efficiency in mind. How to evaluate reasoning models honestly: (1) Benchmark on your actual task distribution — published benchmarks are useful for comparison, but your actual tasks may differ. Test on your real workload. (2) Use contamination-resistant benchmarks — LiveCodeBench, AIME (new problems each year), FrontierMath. Avoid benchmarks that may be in the training data. (3) Measure token efficiency — track tokens per query, not just accuracy. A model that scores 90% with 50K tokens may be worse than one that scores 85% with 5K tokens for production. (4) Measure latency — track p50, p95, p99 latency. Reasoning models have high variance in thinking time. (5) Measure cost per correct answer — not cost per query. A cheaper model that gets more wrong answers may cost more in retries. (6) Test with your prompts — reasoning models respond differently to different prompts. Test with your actual prompts, not just benchmark prompts. (7) Test edge cases — reasoning models should excel at edge cases. Test them there. (8) Don't evaluate on simple tasks — reasoning models often appear worse than standard models on benchmarks that measure speed, cost per query, or performance on simple tasks. Evaluate them on the right tasks. The key: 'Reasoning models often appear worse than standard models on benchmarks that measure speed, cost per query, or performance on simple tasks. Evaluating them on the wrong tasks leads to incorrect conclusions.' Use the right benchmarks for reasoning: AIME, GPQA, ARC-AGI, SWE-Bench, LiveCodeBench. And always benchmark on your actual task distribution (prompt20 2026, zylos 2026, pr-peri 2026)."