← graph

design-named-profiles

Design: named profiles for runtime model/endpoint switching

Metadata

Statusdone
Assignedagent-1015
Agent identityf51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e
Modelclaude:opus
Created2026-04-28T23:07:42.979211167+00:00
Started2026-04-28T23:13:33.950085618+00:00
Completed2026-04-28T23:20:46.558195506+00:00
Tagspriority-high,design,profiles,config, eval-scheduled
Eval score0.82
└ blocking impact0.85
└ completeness0.85
└ coordination overhead0.90
└ correctness0.85
└ downstream usability0.85
└ efficiency0.80
└ intent fidelity0.90
└ style adherence0.85

Description

Description

User wants named profiles to switch the entire (model, endpoint, per-role overrides) bundle at runtime without hand-editing toml. Three starter profiles needed:

  • claude — claude:opus worker, claude:haiku for agency meta-tasks
  • codex — codex:gpt-5.5 worker, codex:gpt-5.4-mini for agency
  • wgnext — in-process nex handler with a localhost endpoint (local:<model> -e http://127.0.0.1:8088 shape); user can change the endpoint per-machine

User quote: 'profiles that we can switch at runtime quickly... so we could have several profiles, I think, that are available to us, and make them easy to configure. So there should be claude, codex, and there should also now be wgnext, configured with localhost or something, but then we can just change the endpoint there.'

Goal

Decide the profile system shape and document it. Hand off concrete spec to the implementation task.

Forks to resolve

Storage

  • A) ~/.wg/profiles/<name>.toml — one file per profile, full or partial config
  • B) [profiles.<name>] sections inside ~/.wg/config.toml — single-file
  • C) Both — partial overrides under [profiles.<name>] in main config, with a separate file for full snapshots

Recommend A for clarity (one file = one profile = easy to share/version).

Command surface

  • wg profile list — list named profiles + which is active
  • wg profile show [<name>] — print the resolved config (default: active)
  • wg profile create <name> -m <model> [-e <endpoint>] ... — make a new profile
  • wg profile use <name> — switch the active profile (writes the active-pointer somewhere)
  • wg profile edit <name> — open in $EDITOR
  • wg profile delete <name>
  • wg profile diff <a> <b> — show what changes between two profiles

Switching semantics

  • Does wg profile use <name> send a hot-reload IPC to the running daemon (like wg config -m does today)? YES — same UX.
  • Does it affect already-spawned worker agents? NO — they keep their original config. New workers pick up the new profile.
  • Does it affect the chat agent? Open question — chat agents may already be running in different terminals. Probably the chat agent reads its own profile name on startup and stays on that profile.

Profile contents (what fields can be in a profile?)

Minimum: [agent].model, [dispatcher].model, [models.evaluator], [models.assigner], [models.flip], the relevant llm_endpoints entry. Plus: any per-handler env vars that need pinning.

Starter profiles

The fix-codex-cli task is already writing codex defaults — design how those become a profile rather than overwriting the global config. Probably: wg init --route codex-cli creates a codex profile and sets it active, instead of mutating the global default.

Validation

  • Design doc posted to task log via wg log
  • Storage format chosen with rationale
  • Full command surface specified (verb list + args + behavior)
  • Hot-reload semantics defined (running daemon, in-flight workers, chat agents)
  • Profile schema documented (which fields are profile-able, which stay global)
  • Migration path for users on existing ~/.wg/config.toml (default profile name? auto-create from current?)
  • Smoke scenario list: wg profile create, wg profile use, wg profile list, hot-reload check

Depends on

Required by

Log