Designing a Quality-First GPT-5.6 Model Role Matrix for Oh My Pi

Oh My Pi (OMP) exposes several model roles: default, smol, slow, vision, plan, designer, commit, tiny, task, and advisor. At first glance, this looks like a request to choose ten models. It is not.

A role is a routing policy for a particular consumer inside OMP. Some roles drive long-lived interactive sessions, some are used by bundled subagents, and others serve one-shot or background work. Their call frequencies, failure costs, and fallback behavior differ substantially. A useful role matrix must therefore optimize the complete agentic workflow rather than maximize a benchmark score for every individual request.

This article develops a quality-first, latency-aware GPT-5.6 role matrix from that perspective. The final configuration deliberately uses three operating points from the Sol family:

GPT-5.6 Sol xhigh
GPT-5.6 Sol high
GPT-5.6 Sol medium

The configuration contains only public model identifiers and ordinary OMP settings. It contains no API keys, OAuth tokens, account identifiers, private endpoints, machine-specific paths, or usage data.

The central mistake: treating roles as personalities

The role names are not ten independent AI personalities. They are entry points into different parts of OMP:

Several consequences follow from this routing model:

1. task does not control scout, librarian, reviewer, or designer. Those agents use their own roles.
2. Leaving smol or slow unset does not guarantee a cheaper or stronger model. Depending on the resolver path, they can inherit default or use a built-in priority chain.
3. An explicit thinking suffix on a role can override a bundled agent’s own effort selection. For example, pinning task to :high intentionally replaces the task agent’s adaptive thinking behavior.
4. advisor is multiplicative: when enabled, it adds another model call after completed primary turns.
5. tiny can be called far more often than its apparent importance suggests, so even small per-call waste accumulates.

A role matrix should therefore be designed around call topology and failure impact, not role names alone.

My working model: three differentiated operating points

For this workflow, I find the following three-tier abstraction more useful than reasoning about every model-effort combination independently:

This is an effort hierarchy within one model family, not a claim that every benchmark difference is statistically significant.

DeepSWE v1.1 reports Sol max at 73% ± 3% with 60k output tokens and 61 agent steps, Sol xhigh at 71% ± 1% with 41k tokens and 44 steps, and Sol high at 69% ± 1% with 28k tokens and 37 steps.

The upper-tier confidence intervals overlap. Moving from xhigh to max adds only two percentage points at the point estimate while increasing output tokens by about 46% and steps by about 39%. In an agent that repeatedly searches, reads, edits, tests, and retries, that additional work compounds across the tool loop.

The matrix therefore uses high as the standing tier, xhigh for critical gates, and medium for frequent low-risk background calls. It deliberately excludes max.

Design principles

1. Optimize task success, not single-call intelligence

An interactive coding agent may make dozens of decisions before a change is complete:

search -> read -> reason -> edit -> test -> diagnose -> edit -> test

DeepSWE v1.1 reports Sol high at 69% ± 1% with 28k output tokens and 37 steps, versus 71% ± 1%, 41k tokens, and 44 steps for xhigh. For the repeated main loop, high is the clearer quality-and-time operating point.

This is why the main default and general-purpose task roles use Sol high, while Sol xhigh is reserved for explicit review, planning, and vision work.

2. Spend the highest-quality calls where errors propagate

A planning mistake can invalidate every subsequent implementation step. A final review can catch a defect immediately before delivery. These are low-frequency, high-leverage points, so plan and slow receive Sol xhigh.

By contrast, a generated session title is easy to replace and has almost no effect on correctness. That work belongs to Sol medium.

3. Evidence quality matters before implementation begins

A strong implementation model cannot compensate reliably for incorrect repository research. If a scout identifies the wrong subsystem or a librarian misstates an external API, the main agent reasons from corrupted evidence.

For this matrix, smol therefore uses Sol high. DeepSWE places it within one point of Terra max while using about 61% fewer output tokens and 51% fewer steps, so the stronger Sol base does not require the slower maximum-effort supporting lane.

4. Bound continuous advisor effort

The advisor runs after completed primary turns. With OMP’s default advisor.syncBacklog set to off, the primary normally does not wait for advisor completion, but the advisor still adds a parallel model call and can contend for provider capacity. Sol high preserves a strong review tier without running xhigh after every turn.

DeepSWE does not evaluate primary-plus-advisor ensembles, so assigning Terra for model diversity would be an unbenchmarked hedge rather than a measured quality or time win. Deterministic tests and static analysis remain the real authority.

5. Keep subagent fan-out bounded

Enabling an advisor for every spawned subagent can multiply the number of calls dramatically. The parent agent already integrates subagent results and can run a Sol xhigh reviewer before delivery. I therefore enable the advisor for the primary session while leaving advisor.subagents disabled.

The final quality-first role matrix

modelRoles:
  # Main interactive implementation: strong fixed reasoning without paying
  # the xhigh latency at every tool-loop decision.
  default: openai-codex/gpt-5.6-sol:high

  # Repository exploration, external research, and mechanical subagents.
  # The shared lane needs strong evidence quality without max-effort work.
  smol: openai-codex/gpt-5.6-sol:high

  # Explicit deep review and the highest-risk reasoning lane.
  slow: openai-codex/gpt-5.6-sol:xhigh

  # Low-frequency image inspection. See the effort-propagation caveat below.
  vision: openai-codex/gpt-5.6-sol:xhigh

  # Planning errors propagate into every implementation step.
  plan: openai-codex/gpt-5.6-sol:xhigh

  # UI/UX work is iterative, so high is preferable to xhigh on every turn.
  designer: openai-codex/gpt-5.6-sol:high

  # Commit generation can include diff analysis, grouping, and changelog work.
  commit: openai-codex/gpt-5.6-sol:high

  # Titles, labels, classifiers, and other low-risk background work.
  tiny: openai-codex/gpt-5.6-sol:medium

  # The general-purpose task agent can implement load-bearing changes.
  task: openai-codex/gpt-5.6-sol:high

  # Continuous second-pass review at the standing Sol effort tier.
  advisor: openai-codex/gpt-5.6-sol:high

cycleOrder:
  # Role-oriented order: smol/default share Sol high; slow escalates to xhigh.
  - smol
  - default
  - slow

advisor:
  enabled: true

  # Review the primary session, but do not multiply every subagent call.
  subagents: false

The selector names are public model identifiers. Authentication remains outside this example and should never be embedded in a published configuration snippet.

Role-by-role rationale

default: Sol high

The main session performs the largest number of consequential model turns. Sol high is the standing interactive choice because latency and output volume repeat at every search, edit, diagnostic, and verification transition. The higher Sol xhigh tier remains available for lower-frequency critical gates.

DeepSWE’s same-family results support that choice: xhigh adds two points at the point estimate but requires about 46% more output tokens and 19% more steps than high. The confidence intervals touch, so representative OMP workloads remain the final authority.

slow: Sol xhigh

The bundled reviewer consumes the slow lane, as do explicit deep-reasoning workflows. Calling this role is an intentional escalation one step above the main execution lane, so xhigh concentrates additional reasoning on the decisions with the largest failure cost without paying max effort.

Typical uses include:

• final correctness review;
• concurrency and state-machine analysis;
• security boundary changes;
• difficult root-cause analysis;
• cross-module migrations;
• review of a completed implementation before delivery.

plan: Sol xhigh

Planning is another deliberate, low-frequency escalation. The asymmetry is important: one xhigh planning call is limited, while a weak plan can cause many implementation and repair calls later.

Sol xhigh is most justified when the plan defines interfaces, schemas, migrations, parallel work boundaries, or large call-site changes. Small fixes that do not enter Plan Mode do not pay this cost.

task: Sol high

OMP’s task role controls the bundled general-purpose task agent, not all subagents. This agent can perform multi-file implementation, execute commands, and spawn further work. For a quality-first setup, it should not be weaker than the primary implementation model.

The explicit :high suffix is intentional. It replaces adaptive effort selection with the same fixed tier as the primary implementation model. Under wide fan-out, medium is the next tuning step, but its lower DeepSWE score makes that a deliberate quality trade rather than a free speedup.

designer: Sol high

Design work often involves a repeated loop of inspecting the current interface, changing components, and checking the result. Sol high keeps this loop responsive relative to xhigh and max while preserving a strong reasoning tier.

DeepSWE does not evaluate screenshot understanding, UI implementation, or visual regression quality, so it cannot establish that every UI coding turn benefits from xhigh. The iterative nature of designer work favors high as the standing role.

vision: Sol xhigh, with an implementation caveat

Image inspection is usually low-frequency and one-shot, so using the upper selected Sol tier is reasonable. However, OMP’s built-in image paths do not all preserve role-level thinking metadata through the final request. Depending on the consumer, vision: ...:xhigh may guarantee the Sol model selection without guaranteeing that reasoning_effort=xhigh reaches the wire.

For a visual task that truly requires deep multi-step reasoning, it is safer to let a full Sol-powered agent inspect the image together with the relevant repository context rather than rely exclusively on a one-shot image-description tool.

smol: Sol high

The name “smol” can be misleading. This role is used by bundled agents such as repository scouts, external-library researchers, and mechanical workers. The first two can materially affect the main agent’s decisions.

Sol high keeps repository and library research on the same capable base model as the primary session. On DeepSWE it scores 69% ± 1% with 28k output tokens and 37 steps, compared with 70% ± 3%, 72k tokens, and 76 steps for Terra max; the latter offers no measured quality-and-time advantage.

commit: Sol high

Commit automation may do more than write a short subject line. It can inspect staged changes, decide which edits belong together, generate changelog content, and produce the final message. These are semantic tasks, especially in repositories with multiple logical changes staged at once.

Sol high provides semantic quality without using a slower maximum-effort lane for output that remains easy for a human to inspect.

tiny: Sol medium

Titles, labels, lightweight classifiers, unexpected-stop analysis, and similar helpers have low failure impact and are easy to regenerate. Sol medium keeps them on the strongest GPT-5.6 base while bounding repeated background work.

Some tiny consumers disable reasoning or use only the selected model object, so the :medium suffix may not always create a medium-reasoning request. The important policy is that frequent background work does not silently inherit the standing high tier.

advisor: Sol high, enabled

The advisor provides a second pass after completed primary turns. In this configuration, both the primary model and continuous reviewer use Sol high, while explicit final review uses Sol xhigh through the slow lane.

The resulting quality pipeline is:

Sol high primary implementation
        + Sol high asynchronous advisor when enabled
        -> Sol xhigh plan/reviewer/vision escalation
        -> tests, type checking, and static analysis

The advisor uses the same model and effort as the primary, so it should not be treated as an independent safety oracle. Deterministic verification still matters more than model agreement.

With the default advisor.syncBacklog: off, disabling the advisor removes a parallel call and possible contention but does not reliably reduce primary-turn latency. Lowering default effort is the direct latency lever, with a corresponding quality cost.

Benchmark evidence and its limits

The role matrix uses public benchmark results as directional evidence, not as a direct OMP leaderboard.

DeepSWE v1.1: same-family quality and work

DataCurve’s DeepSWE v1.1 evaluates 113 long-horizon software-engineering tasks under mini-swe-agent. Its all-effort view reports:

The point estimate rises with effort, but the marginal work grows quickly:

• max gains two points over xhigh while using about 46% more output tokens and 39% more steps.
• xhigh gains two points over high while using about 46% more output tokens and 19% more steps.
• high gains eight points over medium for about 56% more output tokens and 19% more steps.

The upper-tier confidence intervals overlap, so max has the highest point estimate but is not proven to be a universally superior operating point. This matrix treats high as the standing quality-and-time knee, preserves xhigh for consequential escalation, and reserves medium for low-risk background work.

Why the matrix uses only Sol

The same leaderboard provides the relevant cross-family comparison:

At the reported point estimates, Sol xhigh scores one point above Terra max while using about 43% fewer output tokens and 42% fewer steps. Sol high is only one point below Terra max while using about 61% fewer tokens and 51% fewer steps, and it exceeds Luna max while using about 62% fewer tokens and 64% fewer steps.

Because cost is not the primary constraint, Terra and Luna provide no observed quality-and-time win for these roles. Using them for diversity would be an unbenchmarked ensemble hypothesis, not a leaderboard-derived advantage.

Important limitations

• DeepSWE v1.1 runs mini-swe-agent, not OMP, so its pass rates do not transfer directly to this harness.
• Output tokens and agent steps measure work, not wall-clock latency; provider and transport behavior still matter.
• The upper Sol confidence intervals overlap, so small point-estimate differences should not be overstated.
• DeepSWE is a coding benchmark and does not establish visual or UI quality.
• The commit, tiny, and advisor mappings are inferences from role frequency and failure impact, not directly benchmarked workloads.
• DeepSWE does not test advisor ensembles or the effect of parallel review.
• API latency through a subscription or OAuth-backed Codex route may differ from the benchmark environment.

The appropriate final test is a representative OMP workload: repository search accuracy, patch correctness, test pass rate, review true positives, review false positives, first useful tool-call latency, total wall-clock time, retries, and successful-task cost.

Provider and context boundaries

The example uses exact openai-codex/gpt-5.6-* selectors because exact identifiers avoid ambiguity between providers. An OpenAI API-key route and a ChatGPT/Codex subscription route may expose different context metadata, quotas, pricing, or transport behavior even when the model family name is similar.

Do not copy context-window or dollar-per-token assumptions from one route to another. Verify the models exposed by the configured provider:

omp models

All three selected operating points must appear with the requested thinking levels before relying on the matrix.

Applying the configuration safely

Merge the example into the modelRoles, cycleOrder, and advisor sections of the OMP configuration. Do not publish or copy unrelated provider settings from an existing private configuration.

A safe public example should never include:

• API keys or OAuth tokens;
• private proxy or gateway URLs;
• authorization headers;
• account, organization, or project identifiers;
• local session databases or history;
• private repository names or filesystem paths;
• measured personal usage or billing data.

After updating the configuration:

1. run omp models to confirm model availability;
2. start a new session so the role and advisor runtime are initialized from the new settings;
3. verify that the primary model is Sol high;
4. invoke a reviewer and confirm that it resolves through the slow lane;
5. confirm that the advisor reviews the primary session but not every spawned subagent;
6. run normal repository tests rather than trusting agreement between models.

Resumed sessions may retain a previously selected active model, so changing default should not be assumed to rewrite every existing session automatically.

What I would tune first

This is a quality-first matrix, but quality still needs measurement. If the setup becomes operationally too slow, tune one boundary at a time:

1. keep slow and plan on xhigh, but invoke them only for work whose failure cost justifies escalation;
2. reduce task from Sol high to Sol medium under wide, low-risk fan-out;
3. reduce smol or advisor to Sol medium when their workload is demonstrably mechanical;
4. disable the advisor to remove its parallel call and possible contention, without assuming that this will shorten the primary turn.

If the primary turn itself is slow, the direct lever is default: ...:medium; DeepSWE’s eight-point drop from high makes that a measured quality trade. I would not reintroduce max into the standing matrix.

Final perspective

The final matrix is best understood as a risk ladder:

Sol medium
  -> low-risk background work

Sol high
  -> primary implementation, task execution, research, design, commits, and continuous review

Sol xhigh
  -> planning, final review, vision model selection, and the hardest explicit reasoning

The central design choice is not simply “use the strongest model.” It is to use the highest selected Sol tier at the points where an error has the largest downstream cost, while keeping the interactive implementation loop fast enough to search, test, diagnose, and verify repeatedly.

For this quality-and-time OMP workflow, that means Sol high as the standing tier, Sol xhigh for critical gates, Sol medium for low-impact background work, and no standing use of max, Terra, or Luna.

References

• Oh My Pi model roles and role aliases
• Oh My Pi bundled task-agent definitions
• Oh My Pi model resolver
• Oh My Pi advisor documentation
• OpenAI recommended Codex models
• OpenAI GPT-5.6 model guidance
• DataCurve DeepSWE v1.1