omp (Oh My Pi) + JoinGonka Gateway: agente con roles de modelos

Paso 1: instalar omp. Los métodos oficiales del README del proyecto:

# macOS and Linux
curl -fsSL https://omp.sh/install | sh

# Homebrew
brew install can1357/tap/omp

# via Bun (requires Bun 1.3.14 or newer)
bun install -g @oh-my-pi/pi-coding-agent

# Windows (PowerShell)
irm https://omp.sh/install.ps1 | iex

Paso 2: obtener una clave. Regístrate en gate.joingonka.ai/register, confirma tu dirección y crea una clave con el prefijo jg- en la sección «Claves API». Una sola clave y un solo saldo sirven para todos los modelos de la red.

Paso 3: ejecutar el instalador.

npx @joingonka/setup --tool omp

El instalador te pedirá la clave — no se pasa en los argumentos de la línea de comandos para que no quede en el historial del shell — y hará cuatro cosas:

• registrará el proveedor joingonka en ~/.omp/agent/models.yml: la dirección del gateway, el protocolo openai-completions, la clave como literal y tres modelos de la red con sus ventanas de contexto y límites de respuesta reales; el archivo recibirá permisos 600;
• establecerá el modelo por defecto — modelRoles.default en ~/.omp/agent/config.yml — en DeepSeek V4 Flash, pero solo si el rol está vacío o apunta a un modelo que ya no está en la red: no se apropia de tu elección, sino que te indica cómo cambiarla;
• antes de escribir, hará una copia de seguridad del archivo anterior, y dejará el resto de proveedores, roles y comentarios tal como estaban;
• al final enviará una petición real al gateway y te dirá claramente si la clave, la dirección y el modelo han sido aceptados.

Otro modelo por defecto se define con el flag --model con la abreviatura deepseek, glm o minimax — el modelo indicado explícitamente siempre se escribe. Para dotfiles y servidores hay un modo sin preguntas, en el que la clave se toma de una variable de entorno:

JOINGONKA_API_KEY=jg-your-key npx @joingonka/setup --tool omp --model glm --non-interactive

El instalador tiene en cuenta por sí mismo las ubicaciones no estándar de los configs: un perfil con nombre (OMP_PROFILE) y un directorio de agente movido (PI_CODING_AGENT_DIR). El heredado models.json lo migra a models.yml igual que lo haría el propio omp — los proveedores anteriores no desaparecerán. Y si junto a él hay un settings.json antiguo sin config.yml, el instalador no creará config.yml para que omp no se salte su propia migración de ajustes: te pedirá que ejecutes omp una vez y repitas el comando.

Todo lo que hace el instalador se puede escribir a mano. Son dos archivos, y cada uno tiene su función: models.yml describe los proveedores y los modelos, config.yml guarda los ajustes, incluido qué modelo ocupa cada rol.

# ~/.omp/agent/models.yml
providers:
  joingonka:
    baseUrl: https://gate.joingonka.ai/v1
    api: openai-completions
    apiKey: jg-your-key
    models:
      - id: deepseek-ai/DeepSeek-V4-Flash-0731
        name: DeepSeek V4 Flash (Gonka)
        input: [text]
        contextWindow: 380000
        maxTokens: 32768
        reasoning: true
      - id: zai-org/GLM-5.3-Flash
        name: GLM-5.3 Flash (Gonka)
        input: [text]
        contextWindow: 390000
        maxTokens: 8192
        reasoning: true
      - id: MiniMaxAI/MiniMax-M2.7
        name: MiniMax M2.7 (Gonka)
        input: [text]
        contextWindow: 200000
        maxTokens: 8192

# ~/.omp/agent/config.yml
modelRoles:
  default: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731

La clave como literal es la opción más problemática: omp arranca desde cualquier entorno, y basta con proteger el archivo con chmod 600 ~/.omp/agent/models.yml. Si prefieres mantener la clave fuera del archivo, escribe en apiKey el nombre de una variable, por ejemplo JOINGONKA_API_KEY, y expórtala en la shell desde la que lanzas omp: ese es precisamente el orden de resolución de la clave que describe la documentación del proyecto.

El campo opcional cost (precio por millón de tokens) solo hace falta para estimar el coste de la sesión en la interfaz de omp. El instalador escribe ahí el precio real de la pasarela en el momento de la instalación; en una configuración manual puedes omitir el campo: esa estimación no tiene nada que ver con tu factura, el consumo real lo muestra tu panel.

El selector de modelo se escribe como provider/model-id. El nombre del proveedor se separa por la primera barra, así que los identificadores de la red que llevan su propia barra se escriben tal cual: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731. En lugar de editar config.yml, puedes asignar el rol desde la interfaz, con el comando /model dentro de la sesión o en el asistente omp setup.

En omp, no se selecciona un solo modelo para todo, sino que se asignan por roles; esta es la principal palanca de configuración. Los roles integrados para el diálogo son: default, smol, slow, plan, commit, task, tiny, memory, advisor y vision. No es necesario asignarlos todos: los smol y slow no definidos toman primero el modelo del rol default, los subagentes sin el rol task funcionan con el modelo de la sesión actual, y commit y tiny siguen a smol. Una configuración de una sola línea con default es totalmente funcional.

Dividir los roles entre los modelos de la red no se hace por ahorro —el precio de DeepSeek V4 Flash, GLM-5.3 Flash y MiniMax M2.7 es el mismo—, sino por comportamiento y capacidad: un modelo de razonamiento planifica mejor, un modelo de respuesta larga escribe mejor, y no hay razón para poner tareas triviales en segundo plano en la misma cola que la tarea principal.

# ~/.omp/agent/config.yml
modelRoles:
  default: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731
  slow: joingonka/zai-org/GLM-5.3-Flash
  plan: joingonka/zai-org/GLM-5.3-Flash
  tiny: joingonka/MiniMaxAI/MiniMax-M2.7

retry:
  fallbackChains:
    default:
      - joingonka/zai-org/GLM-5.3-Flash

El bloque retry.fallbackChains es un seguro para horas pico: cuando el modelo principal responde persistentemente con 429, omp transfiere el resto del movimiento a la siguiente entrada de la cadena y, tras una pausa, regresa al principal. La clave de la cadena puede ser un rol, un modelo específico o el proveedor completo (joingonka/*).

Para una ejecución única, el rol se redefine con una bandera: omp --model slow inicia una sesión con el modelo del rol slow, mientras que --smol, --slow y --plan sustituyen el modelo del propio rol. Dentro de la sesión, Ctrl+P alterna entre los modelos de roles y /model abre la selección; en la pestaña Roles ahí mismo se asignan los roles y sus alternativas.

Al valor del rol se le puede añadir un nivel de razonamiento: :low, :medium, :high. Esta es la sintaxis de omp, y cómo un modelo específico interpreta el nivel depende del modelo mismo: en GLM-5.3 Flash, por ejemplo, es un interruptor binario; detalles en la revisión del modelo. Y un detalle útil más: los roles pueden redefinirse para un solo repositorio mediante un archivo <repo>/.omp/config.yml con el mismo bloque modelRoles. Los proveedores y las claves permanecen en el directorio personal, por lo que la clave no terminará en el repositorio.

Primero, verifica que omp detecta el proveedor:

omp models joingonka

La respuesta es una tabla de tres filas con las ventanas de contexto y los límites de respuesta de models.yml, redondeados a miles (la salida está recortada: omp tiene además las columnas thinking e images):

joingonka (3)
model                                context  max-out
deepseek-ai/DeepSeek-V4-Flash-0731      380K      33K
MiniMaxAI/MiniMax-M2.7                  200K     8.2K
zai-org/GLM-5.3-Flash                   390K     8.2K

Después, una ejecución puntual sin interfaz. Coloca en un directorio vacío un archivo con un error evidente y pídele que lo encuentre:

omp -p "Read calc.py and tell me in one sentence whether it has a bug."

El agente debe invocar por sí mismo la herramienta de lectura y responder al grano, indicando la expresión donde está el error. En nuestra ejecución del 21 de septiembre de 2026, este ciclo —consulta, llamada a la herramienta, resultado, respuesta— lo superaron sin problemas DeepSeek V4 Flash y GLM-5.3 Flash; sobre MiniMax M2.7, hablamos en la última fila de la tabla de abajo.

La tercera comprobación es del lado de la pasarela: en el panel, dentro de la sección «Uso», la consulta aparecerá en el desglose «Por modelos», y en el bloque «Por claves» se actualizará la hora de la última consulta. Si ahí no hay nada, omp está llamando a otro proveedor: revisa qué hay asignado a los roles con el comando omp config get modelRoles.

Si algo ha fallado, el diagnóstico suele leerse directamente en el mensaje:

La herramienta agente gasta tokens de forma diferente a un chat: por cada frase suya, omp añade un prompt del sistema y descripciones de las herramientas, y la tarea generalmente requiere varios pasos. En nuestra ejecución, incluso con una sola herramienta de lectura habilitada, cada paso consumía alrededor de 3500 tokens de entrada; con el conjunto completo será más. Por lo tanto, aquí el precio por token es lo que decide.

A través de JoinGonka Gateway, los tokens cuestan $0.0069 por millón de entrada y $0.021 por millón de salida; el precio es el mismo para todos los modelos de la red y se completa en esta página desde una fuente en tiempo real.

Las estimaciones en la columna derecha se basan en los precios de septiembre de 2026. A modo de comparación, cómo se puede pagar por los modelos en omp:

La barra de estado de omp muestra una estimación del costo de la sesión. Se calcula según el campo cost de models.yml: el instalador ingresa allí el precio de la puerta de enlace en el momento de la instalación, y el precio en dólares en la red fluctúa con el tipo de cambio de GNK, por lo que la estimación es solo una referencia. El consumo exacto y el saldo se encuentran en el panel, en las secciones "Uso" y "Facturación". La razón por la que la elección predeterminada recayó en DeepSeek V4 Flash se explica en detalle en el análisis del modelo.

Modo de confirmaciones. Por defecto, omp funciona en modo yolo: aprueba por sí solo la lectura, la escritura y la ejecución de comandos. En tu propio proyecto esto es cómodo; en código ajeno, es motivo para endurecer el modo o pasar a un contenedor:

omp config set tools.approvalMode write

En el modo write, el agente pide permiso solo para ejecutar comandos; en always-ask, también para escribir. Para una sola ejecución, lo mismo se define con el flag --approval-mode. Esto es una propiedad del propio omp y no depende del proveedor del modelo.

Pi y omp son parientes con configuraciones distintas. La configuración de una herramienta no se transfiere a la otra: sus directorios, formatos y nombres de campos son propios de cada una.

Varios entornos. Un perfil con nombre (omp --profile work o la variable OMP_PROFILE) traslada toda la configuración a ~/.omp/profiles/<name>/agent: resulta cómodo para separar claves laborales y personales. El directorio actual del agente se imprime con omp config path.

Si necesitas el agente en el editor. omp puede funcionar dentro de Zed mediante el protocolo ACP: es el mismo agente con la misma configuración, no hace falta volver a definir el proveedor ni los roles.