Ultra Mode

Ultracode / Ultra Mode

Ultracode is a behavioral mode, not a specific tool. When it is active, optimize only for the most complete and correct answer within the user's scope. Token and compute cost are not constraints, but cost freedom does not expand the task scope by itself.

Use whatever independent-work mechanism the environment provides. In this repository, prefer Open Dynamic Workflows (odw). If no independent mechanism exists, use the serial fallback below and disclose that fallback in the final answer.

Scope Discipline

• Treat activation as explicit authorization only. Valid activation can come from the current request, a confirmed session setting, or a direct request for multi-agent, parallel, adversarial, exhaustive, or independent verification.
• Re-evaluate scope for every request, even in a session where the mode is on. Do not let a completed Ultracode task spill into unrelated follow-up work.
• Keep trivial work trivial. If a competent engineer could answer correctly in roughly 30 seconds, answer directly even if the mode is active.
• Match depth to the request. Narrow casual requests get modest fan-out and light verification; explicit "be exhaustive" requests get broader discovery, loop-until-dry exploration, adversarial verification, and synthesis.
• If the request is ambiguous, choose the narrower reasonable scope and state what was and was not covered.
• Add workers or rounds only to close a concrete coverage gap. "Budget remains" is not a reason by itself; "area X is unexamined" is.

Pick The Decomposition Purpose

Before dispatching work, decide which purpose the split serves:

• Coverage: many independent areas exist, such as files, modules, product requirements, or research angles.
• Confidence: one answer is needed, but a single plausible pass may be wrong; gather independent perspectives and challenge them.
• Scale: the task is too large for one pass, such as a full audit, broad migration, or large bug hunt.

Most real Ultracode runs combine at least two of these purposes.

Control Flow

Ask first: can a worker's result be used immediately, or must all sibling results exist before the next step?

• Fan-out / fan-in: dispatch independent units, then merge at a barrier. Use this only when the next step needs the whole batch: deduplication, ranking, "did anyone find a bug?", or final synthesis.
• Pipeline: let each item move through its own stages without waiting for unrelated items. Default to this for multi-stage work like discover -> verify -> write.
• Loop-until-dry: for open-ended discovery, run independent search rounds, dedupe findings, then repeat until 2-3 consecutive rounds find nothing new (raise the threshold for high-risk audits).
• Budget-aware expansion: when the user gives a real effort or token budget, continue expanding coverage and verification depth until the budget is nearly exhausted or no concrete gaps remain.

Typical audit shape: fan out by domain, run loop-until-dry inside each domain, send each surviving finding through an independent verification pipeline, then use one final barrier for deduped synthesis.

Quality Gates

• Adversarial verification: for any non-trivial finding or "fixed" claim, send skeptics whose job is to refute it. The burden of proof is on the claim. Keep the finding only when most serious refutation attempts fail.
• Multi-perspective verification: assign different skeptics to different failure modes: requirements fit, security, performance, concrete reproduction, edge cases, or unexamined assumptions.
• Jury mode: for open-ended design or synthesis, generate several genuinely different proposals, score them independently, then build the final answer from the strongest proposal plus useful ideas from the others.
• Multi-strategy search: when exploring, run different search strategies in parallel so one strategy's blind spots do not define the result.
• Gap review: after you think the work is complete, run a dedicated pass asking what is still missing: unvisited files, unverified claims, unread sources, untested edge cases, or uncovered angles. Treat any real gap as new work, not as a footnote.
• Coverage disclosure: if coverage was bounded in any way, say so concretely in the final answer.