June 2026 será recordado como el momento en que quedó claro que los modelos cerrados pueden desaparecer. Con la remoción de Claude Fable 5 en la memoria reciente, queda más evidente por qué es importante poseer tu stack de IA y saber correr modelos localmente si tu negocio depende de ello.
Qué hicieron y por qué
El equipo detrás de OpenClaw montó un sistema para triagear issues y PRs usando modelos locales (por ejemplo gemma-4-26b-a4b y qwen3.6-35b-a3b) dentro de un agent harness llamado pi. La idea no es reemplazar un clasificador tradicional como BERT, sino aprovechar agentes que puedan pedir contexto, inspeccionar el repo y devolver etiquetas estructuradas.
¿Por qué? Porque correr esto en la nube con una cuenta pagada implica límites y latencia. En hardware local (una GB10 con 128 GB de memoria unificada en su caso) puedes tener notificaciones casi en tiempo real y costes muy bajos (electricidad y mantenimiento).
Arquitectura y flujo técnico
El diseño es sencillo y práctico:
openclaw/gitcrawlmantiene un espejo local del repositorio y normaliza cada evento (issue/PR) en objetos uniformes.localpagerguarda esos objetos en SQLite y crea trabajos de clasificación.- Un worker reclama trabajos, arma un contexto de GitHub (título, body, labels, diffs seleccionados) y lo envía a
localpager-agent. localpager-agentejecuta la lógica agentica: puede pensar, usar un shell restringido (reposhell) para operaciones solo de lectura y finalmente llamar afinal_jsonpara devolver la clasificación en un esquema definido.- La salida se guarda en SQLite y un componente determinista decide si notificar en Discord según políticas configuradas.
Importante: solo la clasificación usa un LLM. Enviar notificaciones es determinista para reducir latencia y errores.
Seguridad: reposhell y límites
No le das un bash completo al modelo. En su lugar usas reposhell, una shell limitada que acepta solo comandos de lectura (ej. ls, cat, rg, git show --name-only). Así evitas que un PR malicioso con prompt injection haga que el modelo ejecute comandos arbitrarios.
Ejemplo de uso (simplificado):
localpager-agent \
--model "<model-id>" \
--base-url "<openai-compatible-base-url>" \
--session-dir "<session-output-dir>" \
--final-schema "<runtime-schema.json>" \
--tools bash,final_json \
--reposhell-socket "<reposhell.sock>" \
-p "$(cat <rendered-prompt.md>)"
Modelos, optimizaciones y resultados
Probó varios modelos locales: gemma-4-26b-a4b, qwen3.6-35b-a3b y usó DeepSeek-V4-Flash como referencia. Algunas optimizaciones clave para Gemma en GB10:
vLLMcon NVFP4 quantization (hardware-friendly)- prefix caching y FP8 KV cache
- CUTLASS MoE backend y modo language-model-only
En evaluación sobre 330 filas (cada item etiquetado por consenso con GPT-5.5 y Opus) encontraron diferencias claras:
| Metric | gemma-4-26b-a4b | qwen3.6-35b-a3b | DeepSeek-V4-Flash |
|---|---|---|---|
| Precision | 0.716 ± 0.010 | 0.831 ± 0.007 | 0.938 |
| Recall | 0.905 ± 0.004 | 0.818 ± 0.006 | 0.714 |
| F1 | 0.800 ± 0.008 | 0.824 ± 0.002 | 0.811 |
| Exact match | 0.410 ± 0.014 | 0.540 ± 0.014 | 0.509 |
| False positives | 227.0 ± 10.5 | 105.7 ± 6.4 | 30 |
| False negatives | 60.0 ± 2.6 | 115.3 ± 4.0 | 181 |
| Wall seconds / row | 1.41 ± 0.04 | 13.51 ± 0.79 | 144.14 |
| Output tok/s / worker | 25 | 50 | 13 |
| Concurrency | 16 | 4 | 1 |
| Total parameters | 26B | 35B | 284B |
Interpretación rápida: Gemma es más rápida y captura más casos (alta recall) pero genera más falsos positivos. Qwen es más conservadora (más precisión y exact match) a costa de algo más de tiempo por fila. DeepSeek es muy precisa pero demasiado grande y lento para la GB10.
Metodología y auditoría
Para tener una referencia sólida, etiquetaron 330 items y usaron un proceso de adjudicación: cada item fue etiquetado varias veces por modelos SOTA (GPT-5.5 y Opus) y solo se aceptaron etiquetas con acuerdo. Además, ejecutan un audit loop: cada 2 horas corren un job con GPT-5.5 (cloud) que actúa como juez para identificar falsos positivos y negativos. Esto ayuda a calibrar el sistema antes de confiar 100% en el modelo local.
Costo de la auditoría: en su implementación la revisión batched de GPT-5.5 consume alrededor de 40k tokens cada 2 horas, unos 2-3 centavos por ejecución, o aproximadamente 9 USD/mes a 12 runs/día. Es un precio de calibración, no parte obligatoria del diseño final.
Casos de uso y límite de aplicabilidad
El patrón —que aquí podríamos llamar agentic classification— no es exclusivo de repos open source. Aplicaciones naturales:
- Clasificar noticias en redacciones
- Filtrar posts relevantes en redes y foros
- Triaging de tickets de soporte
- Revisar apelaciones de moderación
- Filtrar leads o investigaciones en arXiv
Recomendación práctica: para prototipos rápidos y dominios cerrados, modelos medianos locales que one-shot clasifican bien sin fine-tuning son una excelente primera opción. Para producción a escala, piensa en un mix: local para filtrado en tiempo real + auditoría periódica con un modelo SOTA en la nube.
Lecciones y recomendaciones técnicas
- Tener hardware con memoria unificada (GB10/Blackwell, 128 GB) facilita batching y alta concurrencia.
- NVFP4 y vLLM ofrecen grandes mejoras en throughput frente a GGUF Q4_K_M en esa topología.
- Protege el entorno: usa shells limitadas, herramientas
final_jsony esquemas obligatorios para evitar salidas inesperadas. - Reserva GPU para tareas que realmente requieren inferencia; usa reglas deterministas donde puedas.
- Evalúa precisión vs recall según tu notificador: si los falsos positivos son costosos (ruido en Discord), elige modelos con mayor precisión o añade reglas post-procesamiento.
La idea central es simple: puedes montar un sistema de triage en tiempo real, con costo marginal muy bajo, y con resultados competitivos si combinas agentes locales, medidas de seguridad y un loop de auditoría con modelos SOTA.