Efficiency and optimization

BMAD's speed, cost, and quality all trace to one thing: how well you manage the model's attention and your own. Waste shows up as context bloat, redundant work, ceremony the task did not justify, the wrong model at the wrong effort, and rework from mistakes caught late. This page is the systematic way to find and remove each, building on the model and token strategy from page 12 and the memory and measurement model from page 7.

On this page

• The one idea
• Lever 1: context discipline
• Lever 2: caching
• Lever 3: parallelism, where it helps
• Lever 4: right-size the ceremony
• Lever 5: model tiering
• Lever 6: reduce rework (the compounding one)
• Lever 7: move work off the metered path
• Lever 8: extend precisely
• Lever 9: measure, then tune
• The inefficiency anti-patterns
• Hands-on: cut a workflow’s context and measure it
• Under Claude Code: context-management internals

The one idea

Everything below is a special case of: keep the working set small, do each unit of work once, and spend capability in proportion to stakes. BMAD is already built around this (just-in-time step loading, externalized state, a fresh chat per workflow, scale-adaptive tracks); optimization is mostly using those on purpose rather than fighting them.

Lever 1: context discipline

The cheapest tokens are the ones you never load. BMAD's internals (page 11) already do most of this; your job is not to undo it.

• Let just-in-time loading work. Complex workflows load one step file at a time rather than the whole procedure up front. Do not paste an entire epic into one chat "so the agent has context"; give it the story, and let it read what it needs.
• A fresh chat per workflow is an optimization, not a chore. It keeps stale reasoning out of the window, and because state is on disk, nothing is lost. Mixing three workflows in one chat both bloats context and risks contradictory documents.
• Keep project-context.md lean and unobvious. It loads on every implementation workflow, so every line is a recurring tax. Record the patterns an agent would miss, not standard practice it already knows.

Lever 2: caching

BMAD re-reads its state from files each workflow, and a stable prefix (frozen system prompt, fixed tool list, a large but unchanging project-context.md) caches: reads cost about a tenth of base input price. The discipline that makes it work is the same the method already teaches, keep the stable content first and the volatile content (today's question) last. The way to lose it is to interpolate a timestamp, a per-run id, or a per-user string into the front of a workflow's context. A fresh chat does not throw the cache away, because the cache is keyed on the reused prefix, not the conversation. (See page 12 for the economics.)

Lever 3: parallelism, where it helps

Parallel agents buy wall-clock and independent perspectives, at a large token premium (research fan-out runs roughly an order of magnitude more tokens than a single-agent chat). Use it where work genuinely decomposes and skip it where it does not:

• Deep Recon's fan-out parallelizes a research sweep across independent sub-questions; the effort preset is the dial (2 / 3 / 6 assistants).
• The BMad Loop and dev-auto dispatch independent stories to concurrent fresh-context sessions.
• Party mode is not parallelism for throughput in its default (session) mode; it is one context voicing several personas. Use subagent mode when you need genuinely independent opinions, and accept the token cost.

The rule: parallelize sweeps and independent items; serialize judgment. Six assistants on a question one focused assistant could answer is pure waste.

Lever 4: right-size the ceremony

The single biggest efficiency lever is running only the phases the work justifies.

• Pick the track by stakes. Quick Flow for a bugfix; the full method for a multi-epic feature; enterprise gates only for regulated or high-blast-radius work. Running the enterprise track on a one-file change is the most common over-spend of human time.
• Set effort per phase, not globally. xhigh for coding and agentic work, high for most judgment, medium/low for mechanical or scoped work, max only when correctness dominates cost. Effort maxed everywhere burns tokens and can cause overthinking (see page 12).
• Loosen gates.mode as trust grows. Start at per-story approval; move toward per-epic or unattended as your measured defect rate earns it. Every gate is human latency; keep the ones that catch real mistakes and drop the ones that only rubber-stamp.

Lever 5: model tiering

Judgment on the strong tier, mechanical work on the cheap tier. The two BMAD surfaces that expose this are Deep Recon's subagent_models (lead strong, researchers a tier down, mechanical extraction on a fast tier) and the BMad Loop's per-stage mux (implementation on your best coding model, review on another). Everywhere else it is the host's model selector plus a fresh chat between phases so you can switch model without dragging context. Full guidance on page 12.

Lever 6: reduce rework (the compounding one)

Every mistake caught late is paid twice: once to make it, once to unwind it. The method's cheap checkpoints exist to move that catch earlier.

• Frame before you build. A forge-idea kill criterion kills a bad idea in one exchange instead of a shipped quarter. This is the highest-return minute in the whole process.
• Run the readiness gate. A CONCERNS caught as a paragraph is free; the same defect caught in code review costs a dev-story round trip.
• Reconcile upstream, not downstream. When documents disagree, fix the owning document (bmad-prd Update, bmad-correct-course) and let it propagate; do not hand-patch every downstream file.
• project-context.md is the compounding asset. Every mistake you turn into a line here is a mistake no future story repeats. A team that feeds retrospective and correct-course lessons back into it gets monotonically more efficient; one that does not repeats the same corrections forever.

Lever 7: move work off the metered path

• Draft mode and web bundles run the expensive part of research (long agentic browsing) on a flat-rate chat subscription, then Process the report back into the repo. For a team this is often the largest single cost saving.
• Batch the mechanical. Bulk, non-interactive work runs at half price through the Batch API.
• Deterministic work belongs in code, not prose. Deep Recon hands its counting to recon_kit.py and the BMad Loop is plain Python for exactly this reason: never pay model tokens to imitate something a script does exactly and free (page 11).

Lever 8: extend precisely

The right external tool removes tokens rather than adding them. A symbol-level code tool like Serena lets a dev-story edit by symbol instead of reading whole files into context; an up-to-date-docs tool like Context7 stops the model guessing (and re-generating) an API; a deterministic AST tool applies a change across a codebase without a per-file round trip. Wire these in over MCP where they pay for themselves, and skip the ones that just add another chatty surface. The tool ecosystem page is the catalog and the when-to-add decision matrix.

Lever 9: measure, then tune

Optimization without measurement is superstition. Track the scorecard from page 7 (time to first falsifiable experiment, readiness defects caught early, story rework rate, token cost per workflow, stale claims refreshed), then run a tight loop:

1. Measure where time and tokens actually go across a real cycle.
2. Find the single biggest waste (usually one of: over-effort, a deep research run that should have been quick, ceremony on a small change, or rework from a skipped gate).
3. Apply the matching lever above.
4. Re-measure. Keep the change if the number moved; revert it if it did not.

Two facts make this measurable rather than vibes: Deep Recon's recon_kit.py tally counts claims by status straight from the ledger, and dev-auto's baseline_revision..final_revision brackets exactly what a run produced, so "how much did we redo?" is a git log, not a guess.

The inefficiency anti-patterns

Hands-on: cut a workflow's context and measure it

Lever 1 is only real once you can see the tax. This is a five-minute session that measures your window, removes the biggest recurring line, and confirms the drop.

1. Measure. In a repo, before starting a bmad-dev-story workflow, run /context. It prints the live window by category.

Illustrative (run it in your own repo; not machine-verified here).

Context usage: 48.2k / 200k tokens (24%)

  System prompt        3.1k
  System tools        12.4k
  CLAUDE.md            2.1k
  Skills               1.9k
  MCP tools            4.6k
  project-context.md   6.8k
  Messages            17.3k
  Free space         151.8k

Two lines are yours to move. project-context.md (6.8k) reloads on every implementation workflow, so it is a recurring cost, not a one-off. Skills (1.9k) is capped near 1% of the window; leave it.

2. Trim the recurring line. Open project-context.md and keep only what the model would miss. Before:

## Coding standards
Write clear names, keep functions small, add a test for new
behavior, handle errors explicitly, and log at the boundaries.

## Queues
Every job goes through `enqueue()`; never call `worker.run()`
directly. The retry and backoff wrapper lives in `enqueue`.

After:

## Queues
Every job goes through `enqueue()`; never call `worker.run()`
directly. The retry and backoff wrapper lives in `enqueue`.

The coding-standards paragraph is standard practice the model already applies; the queue rule is the non-obvious one it would miss. Dropping the paragraph subtracts those tokens from every future implementation workflow, not just this one.

3. Drop stale conversation. Before the next workflow, /clear. It resets the window, and because BMAD state is on disk (page 7), nothing is lost. This zeroes the Messages line.

4. Shrink the scripted baseline. For a non-interactive batch, --bare strips hooks, skills, MCP, and CLAUDE.md:

claude -p "run bmad-dev-story for STORY-142" --bare

Every run in the batch then starts from the smaller baseline.

5. Re-measure. Run /context again after the trim and /clear.

Illustrative (run it in your own repo; not machine-verified here).

Context usage: 26.6k / 200k tokens (13%)

  System prompt        3.1k
  System tools        12.4k
  CLAUDE.md            2.1k
  Skills               1.9k
  MCP tools            4.6k
  project-context.md   2.5k
  Messages             0.0k
  Free space         173.4k

project-context.md fell 6.8k to 2.5k and Messages went to zero: about 22k of window handed back, repeated on every workflow. That is the loop in Lever 9, made concrete on one knob.

Under Claude Code: context-management internals

BMAD is host-agnostic, but each lever above lands on a concrete Claude Code knob. Start by seeing the live budget: /context prints a per-category breakdown (system prompt, CLAUDE.md, skills, loaded files, conversation, MCP tools), so "context discipline" (Lever 1) stops being a guess.

When the window nears ~95%, Claude Code auto-compacts: it clears older tool outputs first, then summarizes earlier conversation. /compact [focus] triggers that manually with a focus string, and a PreCompact hook can fire before it. /clear is the chapter's "fresh chat per workflow" made literal, and it is safe for exactly the chapter's reason: BMAD state lives in files, so nothing is lost when the window resets.

Subagents launched through the Agent tool run in their own windows and return only a final result, so their intermediate context never counts against the parent. That is Lever 3's parallelism with a real cost boundary. --bare strips hooks, skills, MCP, and CLAUDE.md to cut baseline tokens for a scripted, non-interactive run.

Two budgets shape what to keep. The skills listing is capped at roughly 1% of the window, and compaction preserves a bounded per-skill budget, so a lean, unobvious project context (only what the model would miss, per Lever 1) is the highest-value line to hold. And Lever 2 is literal here: a stable prefix keeps the cache warm; a volatile one (a timestamp, a per-run id) throws it away.

Efficiency, in the end, is the same discipline as quality: spend attention where it has the most leverage and nowhere else. The next page is the toolbox that several of these levers reach for, the open-source memory and code tools that extend a BMAD agent, and exactly when each one earns its place. 👉