| name | adaptive-model-orchestrator |
| description | Route substantive coding, planning, architecture, debugging, review, security, and research across the active coordinator, an independent external model family such as OpenCode/GLM, and optional fast, balanced, or deep Codex peers. Use when adaptive multi-model orchestration is adopted or requested, including deciding whether normal strong effort is enough or max/ultra is justified. |
Adaptive Model Orchestrator
Keep the active Codex thread as coordinator and final authority. Read
references/ADAPTIVE_MODEL_ORCHESTRATION.md before routing and
references/OPENCODE_DELEGATION.md before using OpenCode.
Capability Gate
- Read current user, repository, privacy, and mutation constraints first.
- Discover the live executable, provider, model, effort, and agent catalog.
- Select the adopted profile:
single-agent, adaptive, or
always-on-two-family. Never silently promote a portable install to
always-on external routing.
- Record the expected latency/cost, context boundary, output cap, stop
conditions, and local fallback.
- Keep offline package validation separate from credentialed runtime probes.
Route
Classify ambiguity, architecture depth, security/data/dependency/release impact,
reversibility, blast radius, validation strength, failed attempts,
disagreement, and decomposability.
- Fast lane: discovery, extraction, classification, log/test triage, or
mechanical verification.
- Standard lane: default plan challenge, implementation critique, debugging,
review, and verification.
- Deep lane: security/data boundaries, irreversible architecture, conflicting
evidence, ambiguous root cause, repeated failure, or final high-risk review.
- Delegating-deep lane: deep difficulty plus multiple independent units.
Use normal strong effort such as xhigh when scope is bounded, evidence is
coherent, changes are reversible, and validation can decide correctness. Use
max for the hardest single reasoning path. Use ultra only when max-level
difficulty also benefits from automatic delegation across independent units.
For the bundled example profile, run at least one GLM lane for each substantive
task only when the operator adopted always-on-two-family. Add Luna-like fast
or Terra-like balanced peers when they own a useful independent lane; add a
Sol-like deep peer only when the reasoning gate justifies it. Model names are
examples—verify the live catalog.
Brief
Every lane receives: objective, role, exact scope and do_not_touch, source
evidence, acceptance criteria, validation commands, security/data invariants,
allowed tools, output cap, stop conditions, and fallback. Keep advisor and peer
work read-only. Partition executor writes by disjoint file ownership.
Invoke
OpenCode example profile:
<skill-root>/scripts/run-opencode-sidecar.sh \
<fast|high|max|audit-high|audit-max|execute-high|execute-max> \
<workdir> \
"<bounded brief>" \
[evidence-file ...]
Optional same-provider peer:
<skill-root>/scripts/run-codex-peer.sh \
<sol|terra|luna|model-id> \
<high|xhigh|max|ultra> \
<workdir> \
"<bounded read-only critique>"
Resolve <skill-root> as the installed directory containing this SKILL.md.
Both wrappers are examples and fail closed when a capability is missing. Use
environment overrides documented in the scripts rather than editing credentials
or machine paths into the package.
Executor modes additionally require OPENCODE_ALLOW_WRITES=1 and a marker file
named .ai-config-kit-sidecar-write-scope at the workdir root. Create the marker
only in a dedicated isolated worktree whose entire contents are safe for the
sidecar to modify; prompt-level file scopes are not an enforcement boundary.
Integrate
Re-read load-bearing files, rerun important checks locally, and reconcile model
claims against source evidence. Report each lane as used, blocked, skipped, or
unavailable. Never infer a check passed. Stop adding lanes when another answer
cannot change the decision or materially reduce risk.
