Epic: Model tag routing for spawn specialization

[grzegorznowak]

Problem

pi-agenticoding spawn always inherits the parent model — there is no way to route a child agent to a specialized model. The operator has to remember and manually switch models before spawning, or accept that review/planning/quick-scan children all run on the same model.

Design approach

This is not automatic model routing (where an LLM decides which model is best for a given task). That pattern has known weaknesses — a router model lacks the domain context needed to make informed decisions, and by the time it has grounded in the codebase it might as well do the work itself.

Instead the proposal is operator-defined model groups that the operator explicitly selects when spawning. Each group bundles both a model (or set of models) and a thinking level, replacing the existing thinking parameter when a group is specified.

Key properties:

• Operator-driven: the user picks the group (small-and-fast, big-and-slow, computer-vision, etc.) — no automatic task-to-model inference
• Bundled thinking level: each group defines both model(s) and thinking effort; these replace spawns existing thinking` param when a group is active
• Flexible cardinality: a group with one model is deterministic (always that model). A group with multiple models enables weighted selection or rotation
• Meta-model proxy (stretch): registering each group as a logical model/provider (e.g. group/small-and-fast) would give the deepest integration — the group appears as a selectable model everywhere, not just spawn

What we want

User-defined model groups with a TUI settings panel for managing them (add, edit, delete, reorder). Spawn accepts a group (or modelTag) parameter. The plugin resolves the group to a concrete model + thinking level and the child runs with it. Sensible fallback when a group is missing or unresolvable.

Research

• No existing Pi plugin provides arbitrary model grouping with a TUI (searched pi.dev, npm, GitHub)
• Closest packages: pi-model-router (tier-based heuristic routing, ~250-550 downloads/mo, 0 stars), pi-prompt-template-model (frontmatter model switching, ~6.6K downloads/mo, 257 stars)
• pi-agenticoding spawn currently only accepts { prompt, thinking? } — no model or group parameter
• Existing /agenticoding-settings TUI pattern is a good reference for the group management panel

Epic plan

Full epic in: agent_coordination/epics/model-tag-router/MASTER.md (local coordination repo)

Three discrete story silos:

1. Group data layer — JSON schema, persistence (global/project override), group resolution (single-model deterministic, multi-model weighted), thinking-level bundling
2. TUI group management panel — Settings-list UI, add/edit/delete/reorder groups, model assignment, thinking-level per group, override warnings
3. Spawn integration — group parameter on spawn, wiring to resolution from the data layer, system-prompt hints, command registration

Open for discussion

• Should this live inside pi-agenticoding or as a standalone companion plugin?
• Group resolution failures: silent fallback to ctx.model or visible warning?
• Group naming: prefix convention (e.g. group/) to avoid collision with real model IDs?
• Meta-model proxy: worth scoping into the initial epic, or a follow-up?
• Should handoff also support model groups, or spawn-only initially?

[ofriw]

I actually want it for the main agent. I want to be able to define a group of models with weights (so model A with weight=2 will get picked twice as many times over model B with weight=1) and that every /new will choose a new model from the pool. I highly doubt the added complexity in the spawn tool will make a quality difference (might actually hurt since it'd make the tool harder to use) but rotating at the conversion layer probably will yield a noticeable benefit in quality and price.

I'd also want to see it incorporated into a future looping capability so that every loop iteration would pick a different model from the pool leading to faster convergence (effectively applying LLM as judge)

[grzegorznowak]

Then we have a bit tangental needs for this one. I'd like to actually have a few specific models to use at specific points during the SDLC. The rotation feature is less of a desire for me to be had, so we need to come up with a flexible enough model to support both approaches, and anything in between.
I believe that the model will be the same and the difference will lie at the actual configuration level.
ie.
if I set 1 model per group, that's the same as having one model chosen deterministically, always.
If you set 2+ models then the weighted selection will kick in.

When doing a research I noticed one plugin doing model-routing. It was adding a new meta-model that was a proxy for the underlying group/tag or whatever we define. If we implement something along those lines that would allow for a VERY flexible and fully-integrated experience.

[grzegorznowak]

updated description to squash the earlier comments here + the discussion over at Discord