OMP hizo que la programación híbrida con IA finalmente tuviera sentido para mí

Llevo un tiempo experimentando con modelos de lenguaje grandes ejecutados localmente para programar. OpenCode fue una parte importante de ese recorrido porque me entregó una forma práctica de conectar distintos proveedores, ejecutar modelos locales y aprender dónde resultaban realmente útiles. Funcionaba bien, pero seguía buscando un harness que se sintiera más robusto durante sesiones largas y facilitara asignar distintos tipos de trabajo a distintos modelos.

El mérito del descubrimiento es de un compañero de trabajo que mencionó OMP, u Oh My Pi, durante una conversación en la oficina. No tenía idea de que existía este harness y esa recomendación casual me llevó por un camino muy productivo. Después de usar OMP en proyectos reales, esta es la mejor configuración de programación agéntica que he preparado hasta ahora. Se siente rápida, estable y lo bastante confiable como para que pueda concentrarme en el trabajo en vez de pensar constantemente en el harness. Esta sigue siendo una impresión temprana, no un veredicto definitivo, pero OMP ya me ayudó a transformar un conjunto de herramientas de IA en un flujo de desarrollo coherente.

La eficiencia local y el razonamiento en la nube convergen en un punto deliberado de revisión humana.

El harness importa tanto como el modelo

Un modelo de programación nunca trabaja solo. El harness determina qué archivos puede inspeccionar, cómo aplica las ediciones, qué herramientas tiene disponibles, cómo conserva el contexto y si puede utilizar capacidades como servidores de lenguaje, depuradores, navegadores y subagentes. Ese sistema circundante puede cambiar significativamente la calidad del resultado, incluso si el modelo subyacente sigue siendo el mismo.

OMP es un harness para agentes de programación con un núcleo nativo considerable escrito en Rust, construido como un fork de Pi enfocado en programación. Admite modelos alojados y locales, pero su lista de proveedores no fue lo que me convenció. Lo interesante es la ingeniería alrededor del modelo: ediciones ancladas mediante hash que rechazan referencias obsoletas, integración con el Protocolo de Servidor de Lenguaje para inteligencia de código, integración con el Protocolo de Adaptador de Depuración, entornos persistentes de Python y JavaScript, subagentes estructurados, herramientas de navegador y flujos dedicados de revisión y planificación.

El resultado se siente más cercano a entregar al modelo un entorno de ingeniería cuidadosamente diseñado que a simplemente colocar una interfaz de chat dentro de una terminal. Las lecturas de archivos son focalizadas, las búsquedas son rápidas y las ediciones cuentan con protecciones que reducen el ciclo de reemplazos fallidos e intentos repetidos. Rust forma parte de la historia de rendimiento, pero el punto más importante es que OMP trata la capa de herramientas como un producto y no como algo secundario.

Un modelo no necesita hacerlo todo

Es fácil tratar la selección de modelos como una decisión donde el ganador se lleva todo. Elegir el modelo más potente disponible, enviarle cada solicitud y aceptar el costo de la suscripción o la API. Es cómodo, pero no siempre eficiente. Planificar una refactorización grande o investigar un problema de arquitectura puede justificar el razonamiento más potente disponible. Explorar archivos, actualizar código aislado o implementar una tarea claramente delimitada a menudo no lo requiere.

OMP aborda esto mediante roles de modelos. El rol default se encarga del trabajo habitual, smol privilegia el trabajo rápido y económico, slow está pensado para razonamientos más profundos y plan impulsa las sesiones de planificación. Otros roles cubren tareas delegadas, visión, commits y asesores. En vez de volver a elegir un modelo para cada prompt, puedo decidir en qué es bueno cada uno y dejar que el harness mantenga esa división del trabajo.

Mi enfoque es simple: Codex se encarga de la planificación y el razonamiento difícil, mientras que Qwen3.6 realiza trabajo de programación adecuado en mi propia máquina. OMP se ubica entre ambos y yo sigo siendo responsable de definir los límites y revisar el resultado. El modelo es un trabajador seleccionado para una tarea, no la arquitectura del flujo completo.

Mi punto de equilibrio local

Mi computador de escritorio tiene un Intel Core i5-13600K, 32 GB de memoria del sistema y una AMD Radeon RX 7900 XTX con 24 GB de VRAM. No es un centro de datos, pero sí una máquina muy capaz para inferencia local. Con una cuantización y un tamaño de contexto apropiados, puedo ejecutar Qwen3.6 localmente y asignarle tareas de programación significativas sin pagar por cada token.

Existen restricciones reales. El modelo debe caber dentro de la memoria disponible, los contextos más largos pueden reducir el rendimiento y un modelo abierto local no igualará a un modelo de frontera en cada problema de razonamiento difícil. Ejecutar localmente también significa hacerse cargo de una parte mayor de la configuración, incluido el software de servicio, los controladores, la selección del modelo, la cuantización y el ajuste del rendimiento. A cambio, el modelo está disponible siempre que lo necesito, no consume la cuota de una suscripción y el costo marginal de otra tarea es, en la práctica, la electricidad necesaria para ejecutarla.

Cuando un problema necesita razonamiento más potente, puedo moverlo a Codex mediante la suscripción que ya tengo. Esto no busca demostrar que los modelos locales son mejores que los modelos en la nube o viceversa. Se trata de no pagar por la inteligencia más costosa en cada problema. En mi hardware, ese equilibrio es el punto óptimo práctico.

Dónde encaja OMP junto a OpenCode

OpenCode sigue siendo un proyecto sólido. Tiene un amplio ecosistema de proveedores, admite modelos locales y ofrece experiencias en terminal, escritorio y editor. Me ayudó a establecer el flujo local que finalmente me llevó a OMP. La diferencia no es que OpenCode sea malo y OMP sea bueno. Ambos enfatizan cosas distintas.

OpenCode enfatiza el acceso amplio, los agentes nativos de un proveedor enfatizan un ecosistema directo y OMP enfatiza un harness profundo con enrutamiento explícito entre modelos.

Este es un resumen de mis prioridades, no un benchmark ni una clasificación universal. OpenCode hizo que elegir modelos fuera fácil para mí. OMP va más allá al ayudarme a convertir esa elección en una estrategia operativa. No estoy simplemente cambiando de modelo dentro de la misma interfaz. Estoy asignando un trabajo a cada modelo y entregándole un conjunto de herramientas diseñado para desarrollar software.

Cómo divido el trabajo

La configuración es la parte fácil. La habilidad útil consiste en decidir a dónde pertenece cada tarea. Envío a Qwen local el trabajo acotado y fácil de verificar: exploración del repositorio, resúmenes de módulos, actualizaciones repetitivas, pasos aislados de implementación y tareas independientes para subagentes. Estos trabajos se benefician de la velocidad y la disponibilidad, y normalmente no necesitan consumir mi cuota limitada en la nube.

Codex se encarga del trabajo donde un razonamiento débil resultaría más caro que el uso adicional. Esto incluye planificar cambios entre varios sistemas, evaluar decisiones de arquitectura, diagnosticar fallas sutiles, revisar código sensible y cuestionar una implementación antes de integrarla. No estoy reservando Codex solo para emergencias. Estoy usando su razonamiento más potente donde genera el mayor apalancamiento.

Algunas decisiones siguen siendo mías sin importar qué modelo esté activo. Yo decido qué debe hacer el producto, si un requerimiento es correcto, qué riesgos operacionales son aceptables y si el código generado pertenece al sistema. OMP puede coordinar modelos y herramientas, pero no elimina la responsabilidad de ingeniería.

El camino eficiente no es local ni en la nube. Es un enrutamiento deliberado seguido de revisión humana.

Lo que todavía estoy evaluando

Mi experiencia ha sido excelente hasta ahora, pero aún quiero dedicar más tiempo a sesiones largas, repositorios más grandes, compactación de contexto y subagentes locales. También quiero medir cuánto uso de mi suscripción ahorra en la práctica esta configuración híbrida y aprender cuáles de las capacidades avanzadas de OMP pasan a formar parte de mi flujo diario, en vez de seguir siendo funcionalidades que solo admiro en teoría.

Por ahora mantengo el proceso deliberadamente simple. La planificación potente va a Codex. La implementación adecuada va a Qwen local. Cada resultado vuelve a pasar por mi revisión. Esa simplicidad es una de las razones por las que la configuración se siente estable.

La mejor configuración que he usado hasta ahora

Los modelos locales me dieron control y un costo marginal muy bajo. Los modelos de frontera alojados me dieron un razonamiento más potente. Hasta ahora, combinar ambos solía sentirse como mantener flujos de trabajo separados. OMP es el primer harness que he usado que hace que la combinación se sienta intencional.

En mi 13600K, con 32 GB de RAM y una Radeon 7900 XTX, Qwen3.6 me entrega un trabajador local capaz. Mi suscripción a Codex proporciona el razonamiento más profundo que quiero para la planificación y las decisiones difíciles. OMP los conecta sin obligarme a abandonar ninguno de los dos lados. El resultado es el mejor equilibrio que he encontrado entre capacidad, velocidad, confiabilidad y costo.

No estoy listo para afirmar que esta sea la respuesta definitiva. Las herramientas de desarrollo agéntico cambian rápidamente y los casos extremos difíciles solo aparecen con el tiempo. Seguiré probando OMP y planeo volver con una reseña de largo plazo cuando la novedad haya desaparecido. Por ahora, se queda en mi terminal.