Summary

OpenClaw supports enough low-level configuration today to run a practical split workflow:

• daily chat / lightweight operations use the Pi embedded runtime by default
• coding, PR, repository work, and long-running engineering tasks opt into Codex explicitly

However, configuring this safely is currently non-obvious and easy to get subtly wrong. This would benefit from a first-class preset, guided setup flow, or clearer docs/UI affordance.

Why this matters

Users often want OpenClaw as both:

1. a fast always-on chat/ops assistant across channels, and
2. a stronger coding agent for repo work, pull requests, code review, and complex tool-heavy tasks.

Using Codex for every routine chat turn can feel heavier, slower, and more expensive than necessary. But switching to a split setup requires knowing about runtime policy details that are not surfaced as a coherent workflow.

Current workaround

A working setup can be achieved with runtime policy configuration roughly like this:

{
  "acp": {
    "defaultAgent": "pi"
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "openai/gpt-5.5"
      },
      "models": {
        "openai/*": {
          "agentRuntime": { "id": "pi" }
        },
        "openai/gpt-5.5": {
          "agentRuntime": { "id": "pi" }
        },
        "openai-codex/gpt-5.5": {
          "agentRuntime": { "id": "pi" }
        },
        "codex/gpt-5.5": {
          "alias": "codex",
          "params": { "thinking": "xhigh" },
          "agentRuntime": { "id": "codex" }
        }
      },
      "subagents": {
        "model": {
          "primary": "codex/gpt-5.5"
        }
      }
    }
  }
}

The important subtlety is that a nominal openai/gpt-5.5 default may resolve through Codex-backed auth/provider plumbing in some setups, so openai-codex/gpt-5.5 may also need an explicit Pi runtime policy to keep routine chat on Pi.

Pain points

• There is no obvious preset such as daily-pi-coding-codex.
• The UI/model picker does not make the effective runtime policy obvious enough when provider/auth routing changes the effective provider.
• The relationship between model refs, auth provider, runtime provider, and aliases is hard to reason about from the UI.
• Users must know to configure provider/model-scoped agentRuntime.id rather than old whole-agent runtime pins.
• It is easy to accidentally leave routine chat on Codex despite intending Pi, especially when OpenAI/Codex auth routes are involved.
• The single-alias-per-model shape makes it awkward to provide multiple ergonomic names like codex, code, and code-codex for the same explicit coding model.

Proposed improvements

1. Add a guided preset/command, for example:

openclaw models preset daily-pi-coding-codex

2. The preset should configure:

• default daily model on Pi
• Codex model alias for explicit coding work
• subagents on Codex by default, or at least make that choice explicit
• safe auth/runtime policy for OpenAI and OpenAI-Codex provider resolution

3. Add UI affordance in the model/runtime picker showing the effective runtime:

• openai/gpt-5.5 -> Pi runtime
• codex/gpt-5.5 -> Codex runtime

4. Document recommended usage examples:

• routine Telegram/Discord/DM chat uses default model
• coding sessions select codex or a similar explicit alias
• subagents can be configured independently

5. Consider supporting multiple aliases per model target, so users can map codex, code, and code-codex to the same model/runtime policy without duplicate or confusing config entries.

Expected outcome

A user should be able to choose a supported product-level setup like:

Use Pi for normal chat/ops, and use Codex only when explicitly selected for programming work.

They should not need to understand provider-auth routing internals or hand-edit several model runtime policy entries to get a reliable split workflow.