Office Hours — What's the practical difference between ReAct and Planning patterns when building AI agents, and when should I use each?

What’s the practical difference between ReAct and Planning patterns when building AI agents, and when should I use each?

The Core Difference

ReAct (Reasoning + Acting) and Planning follow opposite philosophies about when to commit to a strategy.

ReAct runs a tight loop: the model reasons about the current state, picks one action, observes the result, then reasons again. It’s interleaved—think and act, think and act. The model sees reality immediately and adjusts on the fly.

Planning upfront builds a full strategy before executing anything. The model reasons through the entire problem once, produces a sequence of steps, then hands that off to be executed in order. It’s commit-then-execute.

Why This Matters in Practice

ReAct works better when the environment is unpredictable or outcomes are hard to forecast. If you don’t know what you’ll find when you open a file, or whether an API call will succeed, ReAct lets you adapt mid-task. The tight feedback loop keeps the model aligned with what’s actually happening.

Planning works better when the problem is well-structured and the model’s initial reasoning is reliable. If you’re orchestrating a multi-step workflow where each step depends on the previous one being correct, and you have clear success criteria, planning reduces token waste and latency. You compute the plan once, execute once.

Real Costs

Here’s what bites you in production:

ReAct token economics: Every action loops back through the model. If your task has 15 steps, you’re doing 15 forward passes. On Claude Opus 5 at $5/$30 per M tokens (input/output), that compounds fast. Cursor’s split-model strategy (frontier models plan, cheaper models execute) works around this by using ReAct for planning on GPT-5.6 Sol, then cheaper models like Gemini 3.1 Flash-Lite actually execute—cutting costs from ~$1.94 per task to $1.28.

Planning token economics: One forward pass generates the entire plan. Cheaper up front. But if the plan is wrong, you’ve now got to either abort halfway or call the model again to replan. That’s wasted tokens on a path that won’t work.

Latency: ReAct’s per-step feedback loop adds roundtrips. Planning generates everything in one shot. On Claude Code or Cursor, where you’re waiting for code to execute anyway, this matters less. On API-only usage where latency compounds, it matters more.

When to Use Each

Use ReAct when:

The task involves discovery (search, exploration, debugging). You won’t know what to do next until you see what happened.
The environment is adversarial or uncertain. Recovering from surprises mid-task is cheaper than replanning.
You’re building with frontier models where one good forward pass is your whole budget anyway. Claude Opus 5 or GPT-5.6 Sol doing reasoning? ReAct. Those models are expensive per call but their reasoning is strong enough that tight feedback loops usually converge faster than bad upfront planning.
You’re in an IDE or agent environment (Claude Code, Cursor) where execution happens locally and the model doesn’t see the output live anyway. You’re already doing something like ReAct under the hood.

Use Planning when:

The task is decomposable into independent steps with clear preconditions. Building a data pipeline, running a fixed sequence of API calls, orchestrating a known workflow.
You’re cost-optimizing and using cheaper models for execution. Plan once on Claude Sonnet 5 or Gemini 3.5 Flash, then execute on Gemini 3.1 Flash-Lite or open-source. One expensive step, many cheap ones.
You need reproducibility and auditability. Plans are human-readable. ReAct traces are harder to parse and harder to reason about after the fact.
You’re running agents with high latency constraints. One roundtrip beats 15.

Concrete Example: A File Refactoring Task

ReAct approach:

Model: "I need to understand this codebase. Let me list the directory structure."
[Execute: ls -R]
Model: "Now let me find all references to the old function name."
[Execute: grep -r oldFunctionName .]
Model: "I found 12 files. Let me open the first one."
[Execute: cat file1.py]
Model: "This file imports from module X. Let me check that module too."
[Execute: cat moduleX.py]
... (10+ more loops)

Total tokens: ~60K (multiple roundtrips through frontier model).

Planning approach:

Model: "I'll refactor by: (1) listing files, (2) grepping for references, (3) updating imports in modules A, B, C, (4) running tests."
[Execute all four steps in sequence]

Total tokens: ~8K (one upfront pass through frontier model, cheap execution after).

The planning version is 7x cheaper. But if step 2 finds references in modules you didn’t predict, ReAct recovers; planning either fails or needs to replan.

The Hybrid Approach (What’s Actually Winning)

The pattern emerging in production is neither pure ReAct nor pure Planning. It’s:

Frontier model does planning on a constrained subproblem.
Cheaper model executes that plan with local ReAct loops (tight observe-act feedback for just that step).
Plan fails or changes? Replan on the frontier model for the next subproblem.

Databricks’ GLM-5.2 strategy, Cursor’s recent architecture, and Claude Code’s multi-step workflows all use this. It keeps ReAct’s adaptability for local problem-solving while keeping Planning’s upfront commitment to structure and cost.

Bottom line: Use ReAct for exploratory or adversarial tasks where feedback shapes the strategy; use Planning for well-structured workflows where you can afford one good upfront computation. In production, hybrid approaches that plan at decision points and execute locally usually win on both cost and reliability.

Question via Hacker News