Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#17 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
20/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Aktiv
Tech-Stack
javascript, typescript
Bereich
devtools, tooling

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

grilling

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.

Where What
harness.json + skill frontmatter A capabilities list per harness and a requires list per skill (subagents, parallel, per-spawn-model, transcripts, loop). The build drops or fails a skill whose requirements a harness doesn't meet, instead of shipping a swarm that silently runs serially.
New pi extension in harnesses/pi/ A fork of pi's example subagent extension that takes a model (and a thinking level, if pi supports one per call) on each task. model-roles.md then works unchanged: look up the role, read the override file, pass the model on the spawn.
harnesses/pi/ tokens.md with pi's paths and session format, harness.json with pi model IDs (local llama.cpp models alongside hosted ones), models.md defaults, and agent overlays for go-agent and comment-sicko.
models.md for pi Run the parent and the judgment roles on a strong hosted model. Put swarm workers and the explorer and investigator roles on a local model. Fill the interrogate, arena and architect lists with models from different vendors.
What each harness provides
Capability gstack assumes Claude Code Pi
Spawn subagents with their own context Agent tool The example subagent extension (each subagent is a separate pi process)
Run them in parallel and collect results Background agents The extension's parallel mode: up to 8 tasks, 4 at a time
Choose a model for each spawn model and effort args Gap. The model is set in each agent file's frontmatter
Give each writer its own checkout isolation: "worktree" None, but the runner can run git worktree add itself
Ask the user a structured question AskUserQuestion None. The skills already fall back to plain text
Read past session transcripts (recall, reflect, ketchup) ~/.claude/projects Pi's own session files
Repeat a command ({{loop_command}}) /loop None
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.

Vorherrschende Sprache
TypeScript
Sterne
0
Forks
0
Ø Merge
3 Std. 33 Min.
Gemergte PRs (30 T.)
13

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus gregogun/gstack

Alle Issues in gregogun/gstack

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.