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 GPT-5.6 role matrix from that perspective. The final configuration deliberately uses four operating points:

GPT-5.6 Sol max
GPT-5.6 Sol xhigh
GPT-5.6 Terra max
GPT-5.6 Luna max

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 :xhigh 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: four differentiated operating points

For a quality-first workflow, I find the following four-tier abstraction more useful than reasoning about every model-effort combination independently:

This is an operational hierarchy, not a claim that every benchmark is strictly monotonic.

Artificial Analysis reports a GPT-5.6 Sol Intelligence Index score of 59 at max and 58 at xhigh, but the measured time to first token is approximately 157.7 seconds for max versus 77.7 seconds for xhigh. The aggregate evaluation output volume is also roughly 70 million tokens versus 35 million. Meanwhile, its Terminal-Bench v2.1 results report Sol xhigh at 89.5% and Sol max at 88.0%.

The lesson is not that xhigh is universally better. It is that max is not a free quality upgrade and is not strictly superior on every workload. In an agent that repeatedly searches, reads, edits, tests, and retries, the latency of each decision compounds across the tool loop.

The strongest model should be placed at the workflow’s critical gates, not necessarily at every node.

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

A model that spends twice as long on every transition can reduce the number of validation cycles that fit within a practical session. For the main loop, a near-maximum model with materially lower latency can produce a better end-to-end result than an absolute-maximum model used indiscriminately.

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

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 max.

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

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 a quality-first matrix, smol therefore uses Terra max rather than Luna. This is intentionally more expensive than a cost-balanced configuration, but it protects the inputs to the main reasoning loop.

4. A continuous advisor should not duplicate the most expensive lane

The advisor runs repeatedly. Assigning Sol max to every advisor turn would combine a Sol xhigh primary call with a Sol max review call throughout the session. That is an extreme multiplier with diminishing returns.

Terra max is a better continuous reviewer: it is still a strong agentic model, it uses a different GPT-5.6 base variant from the primary model, and it leaves Sol max available for explicit final review. This is not true cross-vendor independence—both models remain in the GPT-5.6 family—but it avoids merely replaying the same operating point.

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 max 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: near-maximum quality without paying
  # the full max latency at every tool-loop decision.
  default: openai-codex/gpt-5.6-sol:xhigh

  # Repository exploration, external research, and mechanical subagents.
  # Quality-first means research does not fall to the cheapest model.
  smol: openai-codex/gpt-5.6-terra:max

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

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

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

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

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

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

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

  # Continuous second-pass review without running Sol max after every turn.
  advisor: openai-codex/gpt-5.6-terra:max

cycleOrder:
  # A useful manual ladder: Terra max -> Sol xhigh -> Sol max.
  - 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 xhigh

The main session performs the largest number of consequential model turns. Sol xhigh is the quality-first interactive choice because it remains close to Sol max on the independent aggregate index while avoiding approximately half of the measured TTFT and output volume in that evaluation.

Using Sol max as the permanent default would be defensible for isolated one-shot analysis, but OMP is a tool-using agent. Latency repeats at every search, edit, and diagnostic transition. Sol xhigh preserves a high capability ceiling while allowing more feedback and verification cycles.

slow: Sol max

The bundled reviewer consumes the slow lane, as do explicit deep-reasoning workflows. Calling this role is an intentional escalation, so it is the right place to accept maximum latency and cost.

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 max

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

Sol max 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 xhigh

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 :xhigh suffix is intentional. It replaces adaptive effort selection with a fixed quality tier. If parallel fan-out later becomes too slow, task is the first role I would consider reducing to Terra max; I would keep the main default role on Sol xhigh.

designer: Sol xhigh

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

Public GPT-5.6 benchmarks provide limited evidence about screenshot understanding, UI implementation, or visual regression quality. Sol max has strong presentation-oriented results, but those results do not directly prove that every UI coding turn benefits from maximum reasoning. The iterative nature of designer work favors xhigh as the standing role.

vision: Sol max, with an implementation caveat

Image inspection is usually low-frequency and one-shot, so choosing the strongest base model 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: ...:max may guarantee the Sol model selection without guaranteeing that reasoning_effort=max 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: Terra max

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.

A quality-first matrix therefore promotes smol to Terra max. The explicit suffix overrides the bundled agents’ lower default effort levels. That is a conscious trade: more expensive research in exchange for better evidence supplied to the main Sol agent.

commit: Terra max

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.

Terra max provides a strong quality floor without spending Sol calls on a pipeline whose output remains easy for a human to inspect.

tiny: Luna max

This is the only standing role assigned to Luna in the final matrix. Titles, labels, lightweight classifiers, unexpected-stop analysis, and similar helpers have low failure impact and are easy to regenerate.

Some tiny consumers disable reasoning or use only the selected model object, so the :max suffix may not always create a maximum-reasoning request. The important policy is that background work selects Luna rather than silently falling back to an expensive primary model.

advisor: Terra max, enabled

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

The resulting quality pipeline is:

Sol xhigh primary implementation
        -> Terra max continuous advisor
        -> Sol max plan/reviewer/slow escalation
        -> tests, type checking, and static analysis

The advisor remains part of the same GPT-5.6 family, so it should not be treated as an independent safety oracle. Deterministic verification still matters more than model agreement.

If every completed turn must be reviewed by the strongest available model and latency is irrelevant, the advisor mapping can be changed to Sol max. I do not use that as the standing default because it repeats the most expensive lane throughout the session.

Benchmark evidence and its limits

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

Agentic coding results at max effort

Artificial Analysis reports the following Coding Agent Index results in the Codex harness:

DataCurve’s DeepSWE v1.1 long-horizon implementation evaluation reports:

These measurements support three broad conclusions:

1. Sol has the highest observed capability ceiling.
2. Terra remains close enough to Sol to be a strong supporting and review model.
3. Luna is attractive for low-risk work but should not own final correctness in a quality-first setup.

They do not prove that the same differences hold for every OMP role. The published cross-model coding-agent data is largely max-only, while the final matrix also uses Sol xhigh.

Effort does not scale linearly

Artificial Analysis reports the following aggregate Sol measurements:

Those figures explain why Sol xhigh is the standing implementation model and Sol max is the escalation model. A one-point aggregate gain does not justify doubling a repeated cost everywhere, particularly when at least one independent terminal benchmark favors xhigh.

Important limitations

• GPT-5.6 was newly released when this matrix was designed, so independent replication remained limited.
• Artificial Analysis participated in pre-release evaluation for OpenAI. Its measurements are third-party results, but they are not evidence of broad replication by unrelated laboratories.
• The Coding Agent Index evaluates a model together with an agent harness. Results from the Codex harness do not transfer perfectly to OMP.
• The public cross-model agentic results are mostly max-effort comparisons.
• Aggregate intelligence benchmarks are text-focused and do not establish visual or UI quality.
• API latency measurements do not guarantee the same latency through a subscription or OAuth-backed Codex route.
• Benchmark contamination cannot be proven absent merely because a benchmark is recent or uses an isolated verifier.

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 four 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 xhigh;
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, I would change one role at a time in this order:

1. task: Sol xhigh -> Terra max, especially under wide fan-out;
2. advisor: keep Terra max, but disable it for routine sessions;
3. designer: Sol xhigh -> Terra max for straightforward UI work;
4. smol: retain Terra for research-heavy repositories, but consider Luna for purely mechanical agents.

I would not begin by weakening default, plan, or slow. Those roles protect the main implementation and its highest-risk decisions.

Final perspective

The final matrix is best understood as a risk ladder:

Luna max
  -> low-risk background work

Terra max
  -> evidence collection, semantic support, commit analysis, continuous review

Sol xhigh
  -> primary implementation, general task execution, iterative design

Sol max
  -> planning, final review, and the hardest explicit reasoning

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

For a quality-first OMP workflow, that means Sol xhigh for execution, Sol max for critical gates, Terra max for strong supporting work and continuous review, and Luna max only for low-impact background tasks.

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
• Artificial Analysis GPT-5.6 benchmarks
• Artificial Analysis Coding Agent Index methodology
• Artificial Analysis Terminal-Bench v2.1 results
• DataCurve DeepSWE v1.1