Modelos locales triagean PRs del repo OpenClaw gratis | Keryc
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/gitcrawl mantiene un espejo local del repositorio y normaliza cada evento (issue/PR) en objetos uniformes.
localpager guarda 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-agent ejecuta la lógica agentica: puede pensar, usar un shell restringido (reposhell) para operaciones solo de lectura y finalmente llamar a final_json para 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.
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:
vLLM con 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_json y 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.
