Agent models across runtimes

AgentKit defines the workflow and each Agent's specialist instructions. The runtime discovers the installed Agent, launches it, and resolves its model. Choosing a model does not itself launch an Agent or authorize more delegation.

This guide describes the published Kit mappings for the release selected in the docs header. OMP configuration examples follow OMP 18.2.8. Installed Kit versions, user overrides, model access, and runtime versions can change the result; inspect the installed definition and the actual run before assuming a model was used.

When a workflow delegates

A small edit or lookup can stay in the main session. A workflow may delegate when a specialist prompt, independent review, fresh context, or parallel work adds value and your instructions and runtime permit it.

These are opportunities, not a mandatory sequence of Agents. A Skill's explicit mode can add checkpoints: ak:cook --parallel delegates independent work when available, while ak:cook --advice calls kongming after phases, when stuck, on failed verification, and before high-stakes decisions. An expected-red TDD step is not a failed completion check. Use the invocation form installed for your runtime; Skill flags are not universal omp or ak CLI flags.

Compare runtime behavior

Antigravity (agy) uses a separate global projection and strips incompatible model tiers. OpenCode and portable export do not establish an active AgentKit subagent/model mapping. A target accepting Skills or exporting files does not prove it can dispatch every named Agent. See Runtime adapters for broader capability and delivery differences.

Engineer Agent mapping

The following grouping covers all 16 Engineer Agents. The second column is the Kit selector retained for Claude Code. OMP translates it into a role alias; it does not require the model vendor suggested by the original tier name.

No Engineer Agent uses the sonnet or inherit tier in this release, so none selects OMP's @task role.

A selector retained in a file is not proof your account can use it. In particular, verify access before relying on fable counsel. The @plan role selects a model; it does not put a reviewer into read-only plan mode.

Codex pins

Codex uses per-Agent pins rather than the four OMP roles:

For example, Engineer's tester uses the haiku Kit tier but is pinned to Sol / medium on Codex. Its fullstack-developer and planner share the opus tier, but Codex pins them to Luna / max and Sol / medium respectively. Read the top-level TOML fields, not a model: line quoted inside developer_instructions.

AgentKit's Codex integration can expose Agents through the registered local Agent runtime. Merely finding a TOML file is not proof the current session has a callable delegation tool. Follow Agent discovery troubleshooting if the Agent is unavailable.

Cursor defaults and overrides

The current Engineer and Marketing Agents use only the opus, haiku, and fable rows; the other rows apply to Agents authored with those tiers. These are emitted defaults, not a guarantee that every current Cursor account has each model. AgentKit accepts agent_models.cursor.<tier> overrides in its own configuration. User configuration normally lives in ~/.agentkit/config.yaml; project configuration lives in .agentkit/config.yaml. For example, replace the placeholder below with a model ID available in Cursor:

agent_models:
  cursor:
    opus: YOUR_CURSOR_MODEL_ID

ak config prefs set agent_models.cursor.opus YOUR_CURSOR_MODEL_ID writes the same key; add --scope project for the project file. See ak config prefs set.

The project value applies to a project install; a global install uses user configuration. This is a projection-time setting, not a live OMP-style role. After applying the appropriate Kit lifecycle operation, inspect the emitted file. Do not assume editing config changes an already running worker or overwrites a user-modified Agent file.

Marketing Kit differences

Do not apply Engineer's per-Agent Codex table to Marketing Kit. In the published Marketing Codex package, all 32 emitted Agent roles use gpt-5.6-luna with model_reasoning_effort = "max", including kongming and roles also present in Engineer Kit. This is the package default, not a claim that an advice invocation cannot explicitly request a different model.

For tier-based runtimes, use the Marketing Agent's own frontmatter. In this release, Marketing's analytics-analyst, Explore, git-manager, lead-qualifier, scout, scout-external, and tester use haiku (OMP @smol), kongming uses fable (@advisor), and the other Agents use opus (@plan). A name shared with Engineer is not guaranteed to keep the same tier across releases. The same tier-to-role and tier-to-Cursor tables apply. See the Marketing Agent roster and inspect the active installed definition when both Kits provide a name.

Configure OMP roles

OMP normally reads user settings from ~/.omp/agent/config.yml and project settings from .omp/config.yml. A named profile or environment override can change the user root; omp config path identifies the active Agent directory. Project settings override global values, explicit config overlays override those, and runtime overrides take precedence over persisted settings.

Use /model and its Roles view to assign available models to task, plan, smol, and advisor. Equivalently, merge the following shape into your config, replacing every placeholder with a model selector supported by your provider:

modelRoles:
  task: YOUR_PROVIDER/YOUR_WORKER_MODEL:high
  plan: YOUR_PROVIDER/YOUR_PLANNING_MODEL:high
  smol: YOUR_PROVIDER/YOUR_FAST_MODEL:medium
  advisor: YOUR_PROVIDER/YOUR_COUNSEL_MODEL:high

The effort suffix is optional and must be supported by the selected model. The current Kit Agents select plan, smol, and advisor; task still matters for OMP's own Agents and any Agent you point at @task. AgentKit emits the aliases; it does not populate these user model choices. Changing only the main session's model does not remap Agents using explicit roles. slow and plan are separate roles even when you assign the same model.

Override one Agent

For an ordinary OMP task dispatch, selection precedence is:

1. task.agentModelOverrides[agentName].
2. The Agent's frontmatter model, with role aliases expanded through modelRoles.
3. The active parent model, then configured/default fallback when the Agent inherits.

OMP's eval bridge can also supply an invocation-local model override; the ordinary task schema does not expose that field. Names are exact and case-sensitive: Explore is not explore.

For example, merge these entries into existing mappings:

modelRoles:
  review: YOUR_PROVIDER/YOUR_REVIEW_MODEL:high

task:
  agentModelOverrides:
    code-reviewer: "@review"
    kongming: "@advisor"

A custom role named review or REVIEWER does not automatically bind to code-reviewer; the override above creates that connection. You can use a concrete provider/model:effort instead of an alias, but that Agent then stops following changes to the former role. Remove its override to use its frontmatter again. OMP defaults task.agentModelOverrides to an empty mapping; AgentKit does not install a personal kongming override for you.

Keep model choice separate from advisor supervision

Three similarly named controls do different jobs:

To avoid adding another advisory layer to Kongming's own counsel session, keep its per-Agent advisor disabled unless you deliberately need that second layer:

task:
  agentAdvisor:
    kongming: "off"

This does not disable Kongming or prevent AK's --advice checkpoints from spawning it. It only disables a separate advisor attached to that child session. OMP subagents do not opt into advisor supervision by default; per-Agent settings override the Agent's advisor frontmatter. You do not need --advisor merely to use model: "@advisor".

Other controls that can change the run

• task.agentPrewalk can hand a worker to another model; task.prewalk enables the default for the bundled generic task Agent, not every AK Agent.
• task.enableEffort exposes per-task effort hints; task.maxEffort caps those hints, not every explicit model suffix. A task effort hint takes precedence over an explicit model effort suffix, then the Agent's default effort.
• task.maxConcurrency and task.maxRecursionDepth limit execution, not model selection. They do not instruct the main Agent to use the maximum capacity.
• tier.subagent and task.agentServiceTierOverrides control service tier, independently of model and reasoning effort.
• Retry fallback can change the serving model. A configured selector is not proof of the model that completed a task.

Use omp config get modelRoles and omp config get task.agentModelOverrides to inspect configuration. Use Agent Hub (Alt+A) to inspect the launched Agent and its reported model. OMP owns these keys; do not copy them into another runtime's config. See OMP's Agent discovery documentation and settings documentation for its full runtime contract.

Pi, Grok, and runtime-specific extensions

Pi's AgentKit bridge launches a child using the parent's active model when the Agent has no supported model pin. A separate Pi subagent extension may expose subagents.agentOverrides.<name>.model or subagents.defaultModel; those belong to that extension, not OMP and not the AgentKit bridge's automatic config reader. Confirm which tool handled the call before applying an extension's precedence. See Recommended Pi extensions for optional Pi additions.

Grok's Agent projection removes incompatible model frontmatter without replacing it with a vendor-specific pin. Use the model controls your Grok runtime exposes; do not assume an omitted model becomes an OMP role or a particular provider.

Likewise, --advice expresses a workflow request for counsel, not a universal background-advisor implementation. On a runtime that cannot select a separate model, counsel may use the same model as the parent; on one without delegation, report that advisory supervision is unavailable rather than claiming it ran.

Check an unexpected model

1. Identify the Kit, installed version, runtime, scope, and active profile.
2. Inspect the native Agent definition actually discovered, including name casing. A packaged source file or a shadowed global copy is not the active file.
3. Check model overrides before changing roles. In OMP, inspect both task.agentModelOverrides and modelRoles.
4. Separate model, effort, service tier, advisor, and prewalk settings.
5. Confirm the model reported by the running Agent; check fallback and provider access if it differs from the configured selector.

For role descriptions, use Engineer Agents or Marketing Agents. For install and refresh boundaries, use Installing kits.