model-capability-router

Files (31)

• SKILL.md
• openai.yaml · agents/
• advisor-subagent.toml · assets/agents/
• agents-memory-updater.toml · assets/agents/
• auditor.toml · assets/agents/
• ci-watcher.toml · assets/agents/
• coder.toml · assets/agents/
• comment-sicko.toml · assets/agents/
• compatibility-scan-review.toml · assets/agents/
• debugger.toml · assets/agents/
• docs-reliability-review.toml · assets/agents/
• dyl-agent.toml · assets/agents/
• explorer.toml · assets/agents/
• general-worker.toml · assets/agents/
• hard-coder.toml · assets/agents/
• mechanical-debugger.toml · assets/agents/
• memory-curator.toml · assets/agents/
• planner.toml · assets/agents/
• plugin-architect.toml · assets/agents/
• poteto-agent.toml · assets/agents/
• release-checker.toml · assets/agents/
• reviewer.toml · assets/agents/
• startup-review.toml · assets/agents/
• thermo-nuclear-code-quality-review-subagent.toml · assets/agents/
• thermo-nuclear-code-quality-review.toml · assets/agents/
• thermo-nuclear-review-subagent.toml · assets/agents/
• validation-review.toml · assets/agents/
• gpt6-20260922.md · references/
• gpt61-sol-20260929.md · references/
• pstack-role-presets.json · references/
• check-native-agent-profiles.py · scripts/

SKILL.md (first lines)

# Native Model Routing

Use native Codex model, effort and agent selection. Respect the operator's
selected main model and effort; this skill does not switch an active task.
The profiles below are policy recommendations. They do not establish the
current host configuration or model selected by a running task; check those
separately before describing them as configured. Choose the execution
arrangement before a delegated worker's model.
Authorization to delegate alone does not require consulting this router.

When this policy is used inside T3 Code, read the conditional
[T3 transport mapping](references/t3-runtime.md) before dispatch. It maps
existing role choices to host capabilities; it does not replace the native
Codex policy or authorize another model, provider or spending route.

## Execution arrangement

Keep small, tightly coupled work and immediate follow-ups with the agent that
already holds the relevant context. A cheaper worker model alone does not
justify a handoff. Batch related operations rather than delegating each one.

When the operator requests delegation, preserve that workflow for suitable
bounded work. Otherwise delegate when the benefit justifies briefing, startup,
coordination, verification and likely correction costs. Reuse a suitable worker
and its relevant context for related follow-ups, without assuming cache reuse.
Give it the context needed for its acceptance checks.

Parallelise independently executable packages with clear ownership when the
benefit outweighs duplicated context and integration costs. Sequence dependent
work. Faster completion and lower consumption are separate benefits.

Continue the current thread when its context remains useful. A fresh task suits
an independent objective; a full-history fork copies history rather than
providing a clean context.

Keep one visible task per coherent outcome. Use native subagents for useful,
bounded work inside that task. Create a separate user-owned task only on the
operator's explicit request, for an independent or durable outcome, a schedule,
or a required host/cloud boundary.

## Operator profiles

| Profile | Model | Effort | Use |
|---|---|---|---|
| Recommended coordination profile | `gpt-6.1-sol` | `high` | Recommended for sustained coordination, integration and open-ended execution when available; verify the actual host selection separately. |
| Planning, review and difficult decisions | `gpt-6-astra` | `medium` | Habitual Astra setting when its judgment helps. |
| Exceptional reasoning | `gpt-6-astra` | `xhigh` | Rare difficult decisions or unresolved investigations after the task warrants deeper effort. |
| Visual detection and identification | `gpt-6.1-terra` | `low` | Locate or identify elements in an image when additional reasoning does not improve the required result. |
| Visual interpretation | `gpt-6.1-terra` | `medium` | Interpret images, charts, drawings and screenshots. |
| Demanding visual extraction | `gpt-6.1-terra` | `high` | Difficult OCR, structured fields, text localization and demanding counting. |
| Multistep computer use | `gpt-6.1-terra` | `high` | Complete desktop or browser operations with several steps and verify the resulting state; use `xhigh` when the quality gain justifies the added cost and wait. |
| Professional work with tools | `gpt-6.1-terra` | `high` | Starting point for tool-based work with documents, spreadsheets, forms and applications that produces a verifiable deliverable. |
| Exceptional Terra execution | `gpt-6.1-terra` | `max` | Use when demonstrated quality gains justify the additional consumption and latency; not a habitual default. |
| Bounded subtask | `gpt-6-luna` | `high` | Narrow, well-specified work with clear ownership and acceptance checks. |
| Defined execution | `gpt-6-luna` | `xhigh` | Implementation or transformation with a concrete outcome and verification. |
| Substantial execution | `gpt-6-luna` | `max` | Justified when deeper effort materially helps a bounded implementation with observable proof. |

GPT-6.1 Sol high is also available for demanding coding. Choose directly for
the work rather than forcing an Astra escalation.

Prefer Terra when visual interpretation or operating applications is central
to the work. Keep Luna for suitable bounded execution, Sol for coordination,
integration and complex coding, and Astra when difficult judgment warrants it.
A workflow involving a screenshot does not by itself require Astra. Select
effort for the particular workload and the required accuracy, cost and latency;
do not apply one effort to every Terra task or infer that more reasoning always
improves the result. These profiles do not override a fixed specialist binding
or the operator's selected main model and effort.

Choose directly for the task. Use an Astra → Sol → Luna sequence only when
coordination materially helps the outcome; a direct bounded worker or the
current agent is enough when it does not. There is no mandatory model ladder,
failed-attempt retry, coordinator stage, automatic planning/review delegation,
CLI resolver, receipt workflow or mandatory preset wrapper. Requested planning
or review delegation remains available when suitable. Importance alone does
not justify XHigh. A read-only task can still need Astra. Patch size alone does not prove
that Luna suits autonomous systems administration.

Luna Max is available when justified by the work; it requires no repeated
approval merely for that effort. Choose effort for the workload; higher effort does not guarantee better results.
GPT-6 supports cache-preserving effort updates through its documented mechanism;
do not assume every client uses it or that cache is shared across models or tasks.
For the Terra workload and effort tradeoffs behind these profiles, consult
[references/gpt61-terra-20261028.md](references/gpt61-terra-20261028.md).
The GPT-6.1 Sol launch evidence is in
[references/gpt61-sol-20260929.md](references/gpt61-sol-20260929.md). The
historical GPT-6 evidence remains in
[references/gpt6-20260922.md](references/gpt6-20260922.md). These profiles do
not authorise new spending routes, external actions or additional access. Astra
Max and Ultra are outside the habitual palette. Other supported models remain
available when selected by the operator or bound to a specialist.
Honour explicit selections and fixed bindings, including those outside this
palette.

For pstack's three role-aware presets, use the single canonical mapping in
[references/pstack-role-presets.json](references/pstack-role-presets.json).
Equilibrado is the default for unbound roles in a new setup with no existing
role choices. Economia, Equilibrado and Power preserve explicit model/effort
choices, panel lists, aliases, named specialists and the operator's selected
main model/effort. Show a preserved binding that differs from a preset as an
explicit override. If a requested model or effort is unavailable on its
channel, keep it unchanged and mark it as needing a choice. Select either a
role-aware preset or one upstream global budget; never apply the global effort
target over a role-aware preset.

## Changing selection during work

Keep GPT-6.1 Sol high as the recommended policy default and choose
task-specific overrides through the native surface that actually supports them.
Honor an explicit native effort selection, including low; this recommendation
does not require changing a home configuration or an active thread. In CLI,
`/model` changes model and
supported effort within a session. A task follow-up tool may expose model and
effort overrides; use them only when that tool supports the target. Do not
message the current task recursively to simulate self-switching. The current
agent cannot claim to change its own model without an exposed control and
confirmation. Use the existing bounded specialist delegation when suitable.
Changing `config.toml` sets a default, not proof that an active turn switched.

From TheAngryPit/TheAngrySkills, MIT.

More from TheAngryPit/TheAngrySkills