Run gstack on local and non-Claude models via a pi harness

Start by reading harnesses/claude-code/harness.json, the existing harness files, and model-roles.md to understand the current contract. The issue proposes a pi harness, capability requirements for skills, and possibly a ticket runner, but leaves key design choices and pi behavior unresolved. First settle the extension versus generated agent files and missing capability behavior; done means those decisions are tested against a running pi install and the selected scope is implemented.

Problem

Every gstack subagent runs on a Claude model. The Claude Code harness only accepts opus, sonnet, haiku and fable as models (harnesses/claude-code/harness.json), because those are the only values its Agent tool's model takes. That rules out two things:

• Cheap or local workers. Mechanical roles like swarm workers, how explorer and why investigators can't run on a hosted budget model or a local model on a desktop GPU.
• Real model diversity. interrogate, arena and architect rely on reviewers from different model families. In Claude Code they're all Claude, as PLAN.md already notes.

gstack's skills are written in harness-neutral language, so in principle another harness could fill this gap. In practice, they also assume capabilities that the token layer can't supply.

Idea

Add a pi harness that can run local and non-Claude models, and make the capability contract that gstack's skills already assume explicit.

What each harness provides

Interim: an autonomous ticket runner

Until the harness exists, a plain script can run local workers with Claude as the reviewer:

1. Take the next ready-for-agent ticket whose blockers are closed (from /to-tickets).
2. Create a git worktree for it.
3. Run pi -p with a local model to implement the ticket.
4. Run typecheck, lint and tests.
5. Only if those pass, run claude -p with /gstack:interrogate.
6. On a pass, push and open a draft PR. Otherwise, send the findings back to step 3 (at most 2 rounds), then relabel the ticket ready-for-human.

Cron or a systemd timer starts it. The script drives the steps, not a Claude session, so frontier tokens are spent only on reviewing work that already passed the cheap checks.

Findings

• Per-spawn model choice is the main gap. Claude Code passes the model on each call. Pi's subagent extension sets it per agent definition. The defined agents load from ~/.pi/agent/agents/*.md, or from .pi/agents/*.md when the project scope is enabled.
• Generating one pi agent file per role from models.md would avoid the extension work. The cost is that every change to the override file would need a rebuild.
• Running local workers in parallel won't make them faster. On one GPU, llama-server --parallel N divides the throughput and context between N slots, so only a few local workers can usefully run at once.
• interrogate asks the user when it's unsure of the intent. A headless run needs the ticket reference in the worker's commit messages and in the prompt.
• Pi runs commands without asking for permission by default. Workers need a container or a separate user with no push credentials. The runner script does the pushing.

Nothing has been checked against a running pi install yet.

Open questions

• Extension or generated agent files? Is a pi extension that gstack has to maintain worth it, compared with generated agent files that need a rebuild after each override change?
• Effort mapping. Does pi let a spawn set the thinking level? If not, what does effort mean on pi?
• Pi skill loading. Does pi respect disable-model-invocation? What's its syntax for invoking a skill by slash command, and what should skillPrefix be set to?
• Transcripts. What's the format of pi's session files, and is it good enough for recall, reflect and ketchup?
• Loop. Should {{loop_command}} be stubbed on pi, or replaced with an external timer?
• Missing capabilities. When a harness lacks a capability, does the build drop the skill, fail, or ship it with a stub that says what's missing?
• Local model choice. Which local model and quantization actually complete gstack worker tasks reliably? This should be measured on real tickets with benchmark-checklist, not taken from leaderboards.
• Parent model on pi. Which strong hosted model runs go-mode and the judgment roles, and under which billing (API key vs. subscription)?
• Order. Should the ticket runner come first to collect data on how well local models do, or the capability contract?

Next step

Hold a grilling session on the open questions, starting with extension vs. generated agent files and what the build does when a capability is missing. Then write the capability contract, since it pays off even without pi.