Pi + modelos locales: cuando el harness pesa más que el modelo

TL;DR

• El hilo “Game over” de r/ClaudeCode (1.162 puntos, 429 comentarios, 18 de agosto) afirma que modelos locales de ~22 GB ejecutados en Pi superan a Claude Code con Opus 5 High en tareas de código reales publicadas después del cutoff de entrenamiento de ambos
• El titular es discutible; la mecánica que hay debajo no. Dos evidencias independientes apuntan al mismo sitio: el benchmark interno de Databricks encontró que Pi tenía la mayor tasa de acierto de todos los harness probados con Opus 4.8 enviando ~3x menos contexto por turno, y el fork oh-my-pi duplicó la tasa de acierto de 15 modelos cambiando solo el formato de edición
• La razón structural: el prompt de sistema de Pi cabe en ~1K tokens; el de Claude Code ronda los 24K. En un modelo local de 32K de contexto efectivo, esa diferencia es la diferencia entre que tu proyecto quepa o no
• Qué significa para ti: si trabajas con modelos locales, el harness es la palanca más barata que te queda. Si trabajas en la nube, probablemente sigas mejor con Claude Code

El hilo que encendió la semana

“Game over. 22GB local models run in Pi now outperform Claude Code Opus 5 High on real-world coding tasks published after training cutoffs.” Así, sin punto y aparte. El autor elige bien la comparación: tareas posteriores al cutoff eliminan la ventaja de memorización del modelo grande y obligan a razonar de verdad.

El hilo acumuló 1.162 puntos en tres días, que para r/ClaudeCode —un subreddit dedicado precisamente a la herramienta que el titular da por muerta— es una cifra notable. Pero un post de Reddit no es evidencia. Lo interesante es que la afirmación encaja con datos que sí se pueden verificar.

Lo que sí está verificado

El benchmark de Databricks. Según la recopilación de Earendil (la empresa que hoy mantiene Pi), el benchmark interno de Databricks sobre su codebase de millones de líneas encontró que, con Opus 4.8 a esfuerzo de razonamiento xhigh, Pi obtuvo la mayor tasa de acierto de todos los harness probados, con coste significativamente menor que Claude Code y Codex. La causa medida: Pi enviaba aproximadamente 3 veces menos contexto por turno y terminaba las tareas en menos ejecuciones.

El experimento de oh-my-pi. Can Boluk, autor del fork oh-my-pi, cambió únicamente el formato de la herramienta de edición —de str_replace a ediciones ancladas por hash— y mejoró a 15 modelos en una tarde. El caso más espectacular: Grok Code Fast 1 pasó del 6,7% al 68,3%. Mismos pesos, mismo prompt, otro harness. Cuando el formato de edición deja de comerse al modelo, el output deja de colapsar.

Ninguno de los dos experimentos dice “un modelo de 22 GB supera a Opus 5 High”. Los dos dicen algo más útil: la variabilidad entre harnesses con el mismo modelo es del mismo orden que la variabilidad entre modelos con el mismo harness.

Por qué el prompt de sistema lo cambia todo en local

La comparación de fondo la documenta bien la guía de InsiderLLM: Claude Code expone 18+ herramientas especializadas (Glob, Grep, web search, TodoRead, Task, TeammateTool…) cada una con su schema detallado, y su prompt de sistema ronda los 24.000 tokens. Pi expone cuatro herramientas —read, write, edit, bash— con un prompt de ~1.000 tokens. ¿Buscar archivos? rg vía bash. ¿Tareas? Un TODO.md.

Con Opus y 200K de contexto, 24K de prompt de sistema son el 12% de la ventana: caro pero asumible. Con un Qwen o un Gemma de 27-35B en local y 32K de contexto efectivo, esos 24K te dejan 8K para trabajar. El 1K de Pi te deja 31K. Esa es la aritmética que hace que un modelo “peor” rinda mejor en Pi: no es que el modelo sea mejor, es que por fin cabe el proyecto.

El propio Mario Zechner (creador de Pi, antes libGDX) midió una versión de esta idea: un README de CLI de 225 tokens superó a un servidor MCP de Playwright de 13.700 tokens en tareas de automatización de navegador. Bash es universal y barato; cada wrapper MCP cobra peaje en contexto.

Lo que el hilo exagera

Tres matices antes de dar nada por muerto:

1. “Outperform” depende de la tarea. Las tareas posteriores al cutoff favorecen el razonamiento sobre la memoria, y ahí los modelos abiertos de 2026 están muy cerca. En código ofensivo sobre codebases enormes, contexto masivo y multi-archivo, Opus sigue delante. Los propios defensores de Pi lo admiten en los comentarios del hilo.
2. La velocidad sigue siendo brutal. Las mediciones de la comunidad sitúan los agentes locales en torno a 68x más lentos que la nube: ~2 minutos por llamada a herramienta con un modelo de 14B en un M1 Max, frente a 2-3 segundos con Claude. Para agentic coding, donde una tarea son decenas de llamadas, eso es la diferencia entre minutos y horas.
3. El modelo grande también se beneficia del harness bueno. El dato de Databricks es con Opus 4.8, no con un modelo local. El harness barato mejora a todo el mundo; no es una palanca exclusiva de lo local.

Qué haría yo

• Si ya corres modelos locales: deja de pelear con Claude Code + Ollama y prueba Pi u oh-my-pi. El setup está documentado (guía de Pi + Ollama) y el cambio de harness es la mejora más barata disponible hoy
• Si trabajas en la nube: nada de esto te obliga a migrar mañana, pero deja de asumir que el rendimiento de tu agente depende solo del modelo que elijas en /model. El experimento de oh-my-pi demuestra que el formato de una sola herramienta movió 60 puntos de pass rate
• Si evalúas agentes para un equipo: exige benchmarks desglosados por harness y modelo, no solo por modelo. Un comparativo que solo varía el modelo te está escondiendo media varianza

“Game over” no. Pero el mensaje de fondo del hilo —que la capa de scaffolding importa tanto como los pesos— tiene mejor respaldo empírico que la mayoría de titulares que salen de Reddit.

Fuentes

• Hilo original en r/ClaudeCode (1.162 puntos, 429 comentarios)
• Pi Agent Harness — explainx (2026), con la actualización del benchmark de Databricks
• Claude Code vs Pi Agent para IA local — InsiderLLM
• What I learned building a minimal coding agent — Mario Zechner
• oh-my-pi — GitHub