Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#17 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
javascript, typescript
Área
devtools, tooling

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
0
Forks
0
Merge medio
3 h 33 min
PR fusionados (30 d)
13

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de gregogun/gstack

Todos los issues de gregogun/gstack

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.