Build Efficiency exit conditions
Candidate exit conditions for the Build Efficiency type. See the catalog overview for how to adopt these.
Token & cost budgets
| Exit condition | What it checks |
|---|---|
|
Total tokens consumed to complete the feature stays within the declared per-feature ceiling. |
|
Cumulative model spend for the build does not exceed the configured dollar cap. |
|
Prompt (input) tokens across the build stay under the input-token allowance. |
|
Generated (output) tokens across the build stay under the output-token allowance. |
|
No single task exceeds its allotted share of the feature cost budget. |
|
Spend accrues no faster than the planned burn rate for the elapsed build progress. |
|
Feature build cost does not regress beyond a threshold versus the prior baseline for comparable work. |
|
The build stops and reports rather than silently continuing once a hard budget limit is hit. |
Model routing & effort levels
| Exit condition | What it checks |
|---|---|
|
Mechanical steps (formatting, boilerplate, renames) are routed to the designated low-cost model. |
|
Reasoning-heavy steps are routed to the designated high-capability model. |
|
Each step’s requested effort/reasoning level matches the difficulty class assigned to it. |
|
Trivial steps are not sent to premium models when a cheaper model meets the quality bar. |
|
A model-routing policy mapping step classes to models exists and is applied. |
|
Escalation to a stronger model on failure occurs only after cheaper attempts and within a capped count. |
|
Steps proven mechanical mid-build are downshifted to the cheaper model on subsequent runs. |
|
Every step records which model handled it and the routing rationale. |
Iteration & convergence control
| Exit condition | What it checks |
|---|---|
|
The number of retries for any failing step stays under the configured maximum. |
|
The build reaches a passing state within the declared maximum number of attempts. |
|
No step re-attempts indefinitely; a hard attempt cap terminates non-converging loops. |
|
Iteration halts when successive attempts stop reducing the failing-condition count. |
|
The build detects and breaks cycles where edits alternate between two failing states. |
|
Each retry demonstrably changes the artifact or the outcome rather than repeating identically. |
|
Per-phase attempt counts respect their individual limits, not just the global cap. |
|
A stalled step escalates to a stronger model or human rather than looping at the same tier. |
Caching & reuse
| Exit condition | What it checks |
|---|---|
|
Stable prompt prefixes are served from the provider prompt cache above the target hit rate. |
|
Cacheable prefixes are held byte-stable so cache entries are not needlessly invalidated. |
|
Unchanged modules reuse prior build outputs instead of being regenerated. |
|
Resolved dependencies and toolchain artifacts are served from cache across runs. |
|
Previously produced compiled or generated artifacts are reused when their inputs are unchanged. |
|
The same artifact is not regenerated twice within a build when its inputs did not change. |
|
Cache invalidation is limited to entries whose inputs actually changed. |
|
Repeated identical sub-queries within the build reuse a memoized result. |
Context-window efficiency
| Exit condition | What it checks |
|---|---|
|
Prompts include only the relevant spans of a file rather than dumping entire files. |
|
Context supplied per step stays within the target fraction of the model’s window. |
|
Only files and symbols relevant to the current step are retrieved into context. |
|
The same content is not included multiple times within a single prompt. |
|
Large histories are compacted to summaries rather than carried verbatim across steps. |
|
Accumulated context does not grow unbounded across a multi-step task. |
|
Context no longer relevant to remaining steps is evicted before further generation. |
Parallelism & time budgets
| Exit condition | What it checks |
|---|---|
|
Independent tasks with no shared dependencies are executed concurrently. |
|
Tasks with data or ordering dependencies are not run in parallel. |
|
Each build phase completes within its allotted wall-clock time budget. |
|
End-to-end build duration stays under the overall time ceiling. |
|
The number of simultaneous model or tool calls stays within the configured limit. |
|
A phase exceeding its time budget halts and reports rather than running unbounded. |
|
The dependency critical path length stays within its planned maximum. |
Wasted-work detection & minimal re-verification
| Exit condition | What it checks |
|---|---|
|
Only exit conditions touched by the latest change are re-evaluated, not the full suite. |
|
Artifacts unchanged since their last passing check are not re-verified. |
|
Generated output later thrown away without use is detected and reported as waste. |
|
Abandoned exploration branches are pruned rather than continued to completion. |
|
Work not required by any pending exit condition is not generated. |
|
Steps whose outputs are already satisfied by prior results are skipped. |
|
Re-verification scope is computed from the change’s dependency closure, not the whole project. |
|
The ratio of discarded to committed work stays below the configured waste threshold. |