How it works

A controlled path from prompt to proof.

BuildBrake runs before, around, and after Codex. It does not alter the model. It controls the information and limits around the run.

Preflight

A local, zero-token check rejects vague prompts or tasks disconnected from the stated result before Codex starts.

Task sizing

Auto mode classifies narrow work as micro or small. Broad redesigns and repository-wide work remain standard.

Context selection

A local ranker sends short excerpts from likely files instead of a broad repository dump. Proved receipts can improve later ranking.

Execution limits

Each mode sets targets for commands, files, runtime, and new input tokens. Repeated scans and stalled inspection can stop a run.

Verification

Configured checks or adaptive targeted tests run after the agent exits. Subjective visual work still requires human review.

Receipt

The final record contains usage, commands, changed files, runtime, context choice, verification, and the agent finding.

Fresh and reused context

BuildBrake can reuse a project-specific Codex thread when measured reuse remains efficient. After enough comparable runs, it starts fresh when predicted reuse cost is more than 25 percent higher. A fresh run receives a compact handoff with likely files and learned verification.

Execution modes

MicroOne-component CSS, copy, label, icon, or similarly precise work. One likely file and a target below 10,000 new tokens.

SmallNarrow implementation work with a few files, low reasoning, and strict inspection limits.

StandardBroad features, redesigns, refactors, and work that genuinely needs more repository context.

Proof is separate from efficiency

A run can be efficient and wrong. It can also exceed a token target and still produce the correct result. BuildBrake therefore displays resource use and outcome proof separately.