Execution modes

When you cast a task, you choose how much rigor it deserves — not which model runs it. Modes describe the task; the Forge maps them to an execution strategy.

The five modes

Mode	Suited to	What changes
Fast	Small changes, documentation, straightforward fixes	Minimal analysis, single-pass execution, lightweight verification. For work where the plan is obvious and the risk is low.
Balanced	General engineering, moderate analysis	The default. A full plan, standard verification, and a self-review proportionate to the change.
Deep	Migrations, architecture changes, hard debugging	Extended analysis before planning, more aggressive test coverage during verification, and a more skeptical self-review.
Maximum	Large, high-risk, cross-cutting work	Everything Deep does, plus extensive multi-pass review and the tightest permission posture. Slowest, most careful.
Auto-route	You don't want to choose	The Forge picks a strategy from the task's complexity and safety requirements, and tells you which one it picked and why.

Why modes, not model names

Model providers change constantly: names rotate, capabilities shift, pricing moves. Your tasks don't. A billing migration is a high-stakes, cross-cutting change whether it runs on this quarter's frontier model or next quarter's. Naming the mode after the task means your choice stays meaningful as the underlying strategy — model selection, analysis depth, review passes — evolves underneath it.

It also keeps the contract honest: what you are actually buying with a heavier mode is more analysis, more verification, and more review — not a brand name.

In the prototype

Prototype note

In the current prototype, mode selection shapes the deterministic demo only — it changes what the simulated trace shows, not what any model does. No live providers are connected, and no inference runs anywhere. Real execution strategy is planned work; try the simulated version in the Forge.