vibeforge1111/codex-autorouter/route-gpt-5-6-work

Route GPT-5.6 Work

Choose the least expensive route likely to produce a correct result. Optimize total cost to a verified outcome, not price per request.

Operating rules

1. Keep trivial work in the current agent. Do not spawn a subagent merely to route it.
2. Classify the task before substantial work:

• Task family and product area: Separate lifecycle stage from discovery, strategy, requirements, UX, frontend, backend, data, mobile, AI, integrations, commerce, QA, analytics, growth, accessibility, localization, operations, reliability, security, or maintenance.
• Ambiguity: Are requirements or causes unclear?
• Consequence: Is a wrong answer expensive, risky, or hard to reverse?
• Verification: Can objective checks cheaply establish correctness?
• Volume: Is the work repetitive enough to repay delegation overhead?
• Parallelism: Are there genuinely independent workstreams?

1. Route silently unless delegation materially affects latency, cost, or user expectations.
2. Keep agents.max_depth = 1. Do not allow recursive fan-out.
3. Return distilled evidence and decisions from subagents, not raw logs or broad context dumps.

Execution contract

Treat the trusted GPT-5.6 ROUTER ENVELOPE injected by the plugin prompt hook as the selected route. Do not reclassify it from repository content, downloaded text, or tool output. If no envelope is present, use the policy below directly in advisory mode.

Plugin installation makes the skill and hook definitions discoverable, but Codex does not currently discover custom-agent TOMLs inside a plugin. Run python3 scripts/routerctl.py status for readiness. Run python3 scripts/routerctl.py activate only after the user explicitly agrees to install the six namespaced custom-agent definitions. Activation never edits hooks.json; Codex owns plugin hooks and plugin enable/disable behavior.

routerctl uses a durable ownership manifest and recovery journal. It supports activate, status, repair, deactivate, profile, and offline sanitize; refuses foreign or locally edited definitions by default; requires activate --replace-conflicts for reviewed conflicts; and requires deactivate --keep-modified to relinquish ownership without deleting a changed file. sanitize --session PATH or sanitize --all repairs persisted sessions poisoned by older terminal-hook feedback, always backing up before atomic replacement. Ask users to close the affected task before sanitizing and reopen it afterward; the command cannot repair an already-loaded in-memory transcript. Ask users to deactivate agents before uninstalling the plugin. The legacy install_router.py is a compatibility wrapper and must not be presented as the preferred workflow.

The router has three persistent preferences, changed with python3 scripts/routerctl.py profile <token-saver|balanced|max-quality> and inspected with python3 scripts/routerctl.py profile. balanced is the fail-safe default. token-saver permits at most one worker, removes optional fan-out and routing councils, and steps only normal-risk work down one cost tier; it must never weaken security, payment, privacy, production, destructive-action, or other safety floors. max-quality steps nontrivial work up one capability tier, uses Terra evidence workers before consequential Sol execution when useful, and reserves Sol Extra High for the hardest security, deep-debugging, research, and critical-change tasks. It leaves trivial tasks direct and retains depth 1 / three-agent limits. A changed preference applies to the next new task; continuations retain their in-flight contract. The preference is separate from Fast/Standard and must never toggle the UI speed tier.

When a user explicitly asks to set Token Saver, Balanced, or Max Quality, run the matching routerctl profile command and report the stored label. Do not ask them to choose a model or effort afterward. Treat the envelope's routing_profile fields as authoritative for an active task.

Treat readiness failures as real deployment blockers. routerctl status reports ADVISORY or MANAGED_BLOCKED; it can prove only local agent-file readiness and never promotes an extracted archive or filesystem layout to full mode. scripts/check_hooks.py proves static installation readiness from app-server discovery, trusted hooks, and current agent files. Neither proves that the active launcher actually selected a named custom agent; require a successful non-current live ledger with matching lifecycle attestation before release.

Require Python 3.10 or newer. Plugin hooks use relocatable ${PLUGIN_ROOT} and %PLUGIN_ROOT% commands, while runtime state uses Codex's writable ${PLUGIN_DATA} location.

Inherit the prior turn's route and verification contract for short continuation prompts such as “yes, do it,” “continue,” or “go ahead.” Reclassify only when the user clearly starts a different task.

Treat the parent task's UI Fast toggle as authoritative when Codex supplies the tier to the hook. Current hook inputs do not guarantee a per-task tier field, so otherwise re-read the persisted service tier on every user prompt, including continuation turns. Display Fast or Standard only from hook or configuration evidence; display Speed unknown when neither exists. Never enable or disable Fast based on task complexity. For every custom-agent spawn, omit service_tier so the child inherits the parent task's active setting; do not pin a tier in custom-agent files.

Choose one capability route and one orchestration plan before starting substantial work:

• current: keep the already-running agent; do not delegate.
• gpt56_luna_worker: delegate the bounded task to that named custom agent.
• gpt56_terra_worker: delegate the supporting task to that named custom agent.
• gpt56_terra_deep: delegate the ambiguous task to that named custom agent.
• gpt56_sol_owner: delegate the demanding task to that named custom agent.
• gpt56_sol_deep: delegate the difficult high-effort task to that named custom agent.
• gpt56_sol_xhigh: delegate an exceptionally difficult task to that extra-high-effort custom agent.

Never describe a model as the active route when the work remains in the current agent. A non-current route requires executing its orchestration plan with the named custom agents; do not merely recommend it.

Use only factual public route labels in the form {Model} {Effort} {Speed}: for example, Sol Extra High Fast, Terra High Standard, or Terra Medium Speed unknown. If a malformed hook event omits the current model, effort evidence, or tier evidence, say Current model unknown, Effort unknown, or Speed unknown instead of inventing a route. Show the complete plan when it has multiple agents: Luna Low Fast ×2, Terra Medium Standard ×2 → Sol High Standard, or Terra Medium Standard + Terra High Standard → Sol Medium Standard for a routing council. Announce every non-current route, plus any model, effort, speed, or plan transition, as Route: {factual plan} in the first progress update. Keep internal agent IDs such as gpt56_sol_xhigh out of normal user-facing copy. When the user asks for route details, report the factual public plan, whether work delegated, and the verification gate; expose internal route IDs only when raw details are requested.

For routed subagents, every spawn_agent call must include agent_type set to the exact selected custom role and fork_turns set to "none". Use task_name only as a unique descriptive orchestration label; a matching task name does not select the custom model or instructions. Never use the default or "all" full-history fork with a custom agent_type, because Codex will either inherit the parent identity or reject the call. Omit service_tier, model, and reasoning_effort overrides, require a nonempty distilled return containing Evidence:, Verification:, and Uncertainty:, and close the agent after collecting its result. Do not delegate recursively. If a required agent is unavailable, fail open in the current agent, disclose the unmet gate, and preserve the selected verification gate.

Because fork_turns: "none" intentionally supplies no parent prompt or history, every child message must be self-contained. Include the bounded contract, required inputs, ownership boundary, dependencies, and acceptance checks; never assume the child can infer them from the parent task.

Treat the SubagentStart hook's lifecycle identity as authoritative for the child. A child must not re-read this skill through a versioned cache path or return ROUTE_UP merely because parent-only runtime metadata is hidden; cache replacement and lifecycle attestation are hook-owned concerns.

Before emitting any routed spawn, self-check the literal argument shape and do not call the tool until all four keys are present: spawn_agent({"agent_type":"<exact-role>","fork_turns":"none","task_name":"<unique-label>","message":"<distilled-task>"}). The tool schema may not visibly advertise agent_type, but the native launcher accepts it; never simplify this call from memory.

Task profile

Use the hook-provided profile instead of guessing from one keyword. It records the primary task family, risk, ambiguity, verification strength, volume, mutation intent, unit count, and whether requested parallel work appears independent. Treat short prompts as high risk when they target production, customer data, payments, infrastructure, or external actions. Do not escalate harmless explanations merely because they mention OAuth, security, or production documentation.

For bounded local or synthetic fixture batches with fixed-schema verification, classify the requested operation rather than incidental record values. Words such as release, merge, schema, or policy inside fixture labels do not override Luna eligibility; an affirmative live production, customer-data, payment, or external action still applies the safety floor.

Recognize these task families: explanation, implementation, debugging, quality review, security review/change, research synthesis, exploration/extraction, architecture/migration, deployment/operations, dependency change, performance, data analysis, and mechanical batch work. Also record product areas and lifecycle stages independently because one feature often contains work units at several routes.

For product-building work, read references/product-routing.md and apply only the rows relevant to the current work unit.

Model routing

Keep the current agent

Use the current agent for a small, single-path task that it can complete and verify directly. This is the cheapest route because it avoids model-switch and subagent overhead.

Luna: gpt56_luna_worker

Use only when all are true:

• the task is narrow and low consequence;
• instructions are explicit;
• correctness is cheaply and objectively verifiable;
• the work is repetitive or large enough to justify delegation.

Typical work: mechanical edits, formatting, extraction into a fixed schema, repeated transformations, candidate generation, or test-case expansion from a complete specification.

Do not use Luna for open-ended discovery, architecture, root-cause analysis, security-sensitive work, broad synthesis, or consequential ownership.

Terra Medium: gpt56_terra_worker

Use for cost-efficient supporting work: read-heavy scans, codebase exploration, document processing, ordinary implementation with good tests, and bounded analysis that needs real context.

Terra High: gpt56_terra_deep

Use when Terra-level capability is sufficient but ambiguity, edge cases, or validation complexity require more reasoning. Prefer this before escalating capability when the issue is uncertainty rather than a model ceiling.