Tabla de Contenidos

• Primero, aclaremos los tres nombres que todo el mundo confunde
• Tabla comparativa: BYOK, Zen y Go
• Qué cabe realmente en 10 dólares
• El costo real por turno, para poner las cosas en perspectiva
• Mi recomendación: separa el diseño de la ejecución

  • Por qué esto funciona técnicamente
  • El flujo concreto, paso a paso
  • Ejemplo de spec ejecutable
• Casos borde
• Criterios de aceptación
• Verificación

Primero, aclaremos los tres nombres que todo el mundo confunde

OpenCode es un agente de código de terminal, open source, mantenido por Anomaly. Es la herramienta: una TUI donde escribes, un agente que lee tu repositorio, edita archivos, corre comandos y te muestra los diffs. Es gratis y siempre lo ha sido.

OpenCode Zen es otra cosa. Es un gateway de modelos —un intermediario— que el equipo de OpenCode construyó después de encontrarse con un problema real: hay decenas de modelos que dicen servir para programar, pero muy pocos funcionan bien como agentes, y los que funcionan bien dan resultados muy distintos según qué proveedor los sirva. Un mismo modelo puede rendir excelente en un proveedor y mediocre en otro, con la misma etiqueta. Zen es la respuesta a eso: probaron modelos, hablaron con los equipos que los entrenan, negociaron con proveedores para que los sirvieran correctamente, hicieron benchmarks de la combinación modelo/proveedor, y publicaron una lista curada. Se paga por uso, con precios por millón de tokens y sin markup declarado más allá de las comisiones de procesamiento de pago.

OpenCode Go es la tercera pieza, y la más reciente: una suscripción plana de 10 dólares al mes (5 el primer mes) que da acceso a un subconjunto de esa lista —los modelos abiertos— con límites de uso denominados en dólares en vez de en tokens. No es un plan "ilimitado" ni pretende serlo. Es un plan con un multiplicador declarado: pagas 10 y el objetivo del equipo es darte alrededor de 60 dólares de uso.

💡 Consigue $5 de crédito para tus límites de uso Si te registras con este enlace de OpenCode Go, obtienes $5 de crédito que se aplican directamente a tus límites de uso. Prácticamente cubre tu primer mes de prueba antes de gastar un centavo.

Los tres son independientes. Puedes usar OpenCode con tus propias claves de OpenAI o Anthropic y no pagarle un centavo a Zen ni a Go. Puedes usar Zen desde otro agente que no sea OpenCode. Y puedes tener Go y Zen a la vez, que es de hecho lo que yo recomiendo más abajo.

Tabla comparativa: BYOK, Zen y Go

	OpenCode BYOK	OpenCode Zen	OpenCode Go
Modelo de cobro	Gratis (pagas al proveedor)	Pago por uso, prepago con saldo	Suscripción plana
Precio	$0 + lo que gastes en tu API	Según tokens consumidos	$5 el primer mes, luego $10/mes
Catálogo	Cualquier proveedor que soportes	~70 modelos: Claude, GPT, Gemini, Grok, Qwen, DeepSeek, GLM, Kimi, MiniMax	18 modelos abiertos: Grok 4.5, GLM-5.2/5.1, GPT 5.6 Luna, Kimi K3/K2.7/K2.6, Qwen3.8/3.7/3.6, DeepSeek V4 Pro/Flash, MiniMax M3/M2.7, MiMo-V2.5, Hy3
Modelos frontera	Sí, si pagas la API	Sí (Claude Opus 5, GPT 5.6 Sol, Gemini 3.1 Pro, Claude Fable 5)	No, salvo Grok 4.5 y GPT 5.6 Luna
Límites	Los de tu proveedor	Tu saldo y el límite mensual que configures	$12 cada 5 horas · $30/semana · $60/mes
Recarga automática	N/A	Sí: si bajas de $5, recarga $20 (configurable o desactivable)	N/A, es plano
Al agotar el límite	N/A	Recarga o se detiene	Sigues con los modelos gratuitos, o cae a tu saldo Zen si activas "Use balance"
Equipos	Manual	Workspaces con roles, límites por miembro, modelos habilitables (gratis en beta)	Solo un miembro por workspace puede suscribirse
Retención de datos	La de tu proveedor	Cero retención salvo excepciones documentadas	0 días en casi todos; 30 días en Grok 4.5 y GPT 5.6 Luna
Bring your own key	Es el modo por defecto	Sí, puedes usar tus claves de OpenAI/Anthropic dentro de Zen	No
Para quién	Quien ya tiene contratos o créditos	Quien necesita modelos frontera y control fino	Quien ejecuta mucho y decide poco

La lectura rápida de esta tabla: Zen es un catálogo completo con precios de mercado, Go es un subconjunto barato con techo. No compiten, se complementan.

Qué cabe realmente en 10 dólares

Aquí es donde la mayoría de reseñas se quedan cortas, porque repiten el titular —"18 modelos por 10 dólares"— sin explicar la mecánica que de verdad determina lo que puedes hacer.

Go no te da tokens. Te da presupuesto en dólares, y ese presupuesto se consume a la velocidad que marque el precio del modelo que elijas. Hay tres bolsillos simultáneos: 12 dólares cada cinco horas, 30 dólares por semana y 60 dólares por mes. El de cinco horas es un cortafuegos contra sesiones descontroladas; el semanal impide que te fundas el mes en tres días; el mensual es el techo real.

Pero hay una segunda capa que casi nadie menciona y que es la más importante: no todos los modelos tienen el mismo presupuesto asignado. La documentación oficial publica una columna de "usage" por modelo, y ahí se ve que unos traen 60 dólares de uso incluido y otros solo 15. La explicación del equipo es honesta: para la mayoría de modelos consiguieron descuentos por volumen y capacidad de GPU reservada, y trasladan ese ahorro al multiplicador de 6x. Para los que no —porque son muy nuevos o porque su precio público ya viene descontado— el multiplicador baja a 1.5x.

Esto parte el catálogo de Go en dos ligas:

Liga de 60 dólares (multiplicador 6x): GLM-5.2, GLM-5.1, Kimi K2.7 Code, Kimi K2.6, MiMo-V2.5, MiniMax M3, MiniMax M2.7, Qwen3.7 Max, Qwen3.7 Plus, Qwen3.6 Plus, DeepSeek V4 Flash, Hy3.

Liga de 15 dólares (multiplicador 1.5x): Grok 4.5, GPT 5.6 Luna, Kimi K3, MiMo-V2.5-Pro, Qwen3.8 Max, DeepSeek V4 Pro.

Traducido a peticiones reales, según las estimaciones que publica OpenCode con sus patrones de uso observados:

Modelo	Peticiones / 5h	Peticiones / semana	Peticiones / mes	Liga
DeepSeek V4 Flash	31.650	79.050	158.150	60
MiMo-V2.5	30.100	75.200	150.400	60
Qwen3.7 Plus	4.300	10.800	21.600	60
Hy3	4.300	10.750	21.500	60
MiniMax M2.7	3.400	8.500	17.000	60
DeepSeek V4 Pro	3.450	8.550	17.150	15
Qwen3.6 Plus	3.300	8.200	16.300	60
MiMo-V2.5-Pro	3.250	8.150	16.300	15
MiniMax M3	3.200	8.000	16.000	60
Kimi K2.7 Code	1.350	3.380	6.750	60
Kimi K2.6	1.150	2.880	5.750	60
GLM-5.2 / GLM-5.1	880	2.150	4.300	60
Qwen3.7 Max	340	840	1.690	60
GPT 5.6 Luna	2.050	5.100	10.250	15
Qwen3.8 Max	160	400	810	15
Grok 4.5	120	300	600	15
Kimi K3	110	250	490	15

Mira el salto: DeepSeek V4 Flash te da 158.000 peticiones al mes; Kimi K3 te da 490. Es un factor de 320x entre el extremo barato y el caro dentro del mismo plan de 10 dólares. Cualquiera que use Go como si fuera un buffet de "elige siempre el mejor modelo" se va a chocar contra el límite de cinco horas el primer día.

Y hay que dimensionar los números altos con criterio. Una tarea agéntica de verdad —"añade autenticación con JWT a este endpoint, escribe los tests y actualiza la documentación"— no es una petición. Son entre 30 y 150 turnos: leer archivos, proponer un diff, correr los tests, ver que fallan, corregir, volver a correr. Con esa vara, 4.300 peticiones mensuales de GLM-5.2 son aproximadamente entre 30 y 100 tareas medianas al mes. Para un desarrollador individual o un side project, eso es holgado. Para un equipo de cuatro personas compartiendo una cuenta, no lo es —y de hecho no está permitido: solo un miembro por workspace puede suscribirse a Go.

Si lo que buscas es un desglose enfocado solo en el precio y los límites de Go, sin la parte de Zen ni de estrategia, tengo una reseña dedicada: OpenCode Go: precio, límites de uso y si vale la pena en 2026.

El costo real por turno, para poner las cosas en perspectiva

Para entender por qué la estrategia que propongo funciona, sirve calcular cuánto cuesta un turno agéntico típico en cada modelo. Uso un perfil realista y constante —unos 800 tokens de entrada nueva, 60.000 tokens leídos de caché (el contexto del repo, que es lo que domina el gasto) y 250 tokens de salida— y aplico los precios públicos de Zen:

Modelo	Costo estimado por turno	Turnos por cada $1
GPT 5.6 Luna	$0,00166	~600
DeepSeek V4 Flash	$0,00186	~540
MiniMax M3	$0,0041	~240
Kimi K2.7 Code	$0,0132	~76
Claude Sonnet 5	$0,0161	~62
GLM-5.2	$0,0178	~56
Grok 4.5	$0,0211	~47
Claude Opus 5	$0,0403	~25
GPT 5.6 Sol	$0,0415	~24
Claude Fable 5	$0,0805	~12

Estimación propia sobre el perfil descrito y los precios publicados en la documentación de Zen (dentro de Go, algunos de estos modelos se sirven aún más baratos). Tu consumo real variará según el tamaño de tu repositorio y cuánto caché aproveches.

Lo que salta a la vista es que la diferencia entre el modelo frontera y el modelo obrero no es de un 30% ni del doble: Claude Fable 5 cuesta más de cuarenta veces lo que cuesta GPT 5.6 Luna o DeepSeek V4 Flash por el mismo turno, y dentro del plan Go esa brecha se ensancha todavía más. Y aquí viene la pregunta incómoda: ¿de verdad esos 150 turnos de "lee el archivo, aplica el diff, corre el test" necesitan el mejor modelo del mundo?

Casi nunca. Lo que sí necesita el mejor modelo del mundo es la decisión de qué construir y cómo. Y esa decisión son cinco o diez turnos, no ciento cincuenta.

Mi recomendación: separa el diseño de la ejecución

Aquí está el núcleo del artículo. Mi flujo, después de bastante prueba y error, es este: defino el spec con Claude o Grok, y ejecuto el spec con OpenCode Go.

Personalmente uso sobre todo Claude —Opus 5 cuando la decisión es arquitectónica y Sonnet 5 para specs más rutinarios— y Grok cuando quiero una segunda opinión con un sesgo distinto o cuando necesito que el modelo sea directo y no complaciente. Codex funciona igual de bien para esta fase si es tu herramienta habitual; el punto no es la marca, es el rol.

La lógica es la misma que aplicamos en cualquier metodología ágil seria: el refinamiento y la ejecución son actividades distintas, con costos y perfiles de riesgo distintos. Nadie pone a su arquitecto a escribir los tests unitarios, y nadie le pide al junior que decida el modelo de datos. Cuando mezclas ambas cosas en una sola conversación con un modelo frontera, pagas precio de arquitecto por trabajo de ejecución durante horas.

Por qué esto funciona técnicamente

Un modelo de ejecución no necesita creatividad; necesita obediencia y competencia. Si el spec es bueno —si dice qué archivos tocar, qué contrato cumplir, qué casos borde cubrir y cómo se verifica el éxito— entonces la tarea deja de ser "diseña esto" y pasa a ser "transcribe esto a código y valídalo". Modelos como GLM-5.2 o Kimi K2.7 Code hacen eso perfectamente bien.

Cuando el spec es malo, en cambio, el modelo de ejecución empieza a improvisar. Y ahí es donde la gente concluye que "los modelos abiertos no sirven". No es que no sirvan: es que les pediste que hicieran dos trabajos y solo les pagaste por uno.

El flujo concreto, paso a paso

1. Conversación de diseño con Claude o Grok. Sin código todavía. Describe el problema, el contexto del negocio y las restricciones. Pídele explícitamente que te haga preguntas antes de proponer. Aquí gastas entre 5 y 15 turnos de un modelo caro, y son los turnos mejor invertidos del proceso.

2. Genera el spec como archivo. Pide la salida en markdown, con esta estructura mínima: objetivo, contexto (qué existe hoy), alcance explícito, fuera de alcance explícito, archivos a tocar, contratos e interfaces, casos borde, criterios de aceptación verificables y plan de verificación. Guárdalo en el repo, por ejemplo en specs/2026-08-12-auth-jwt.md. Que viva en git es parte del punto: es documentación y es trazabilidad.

3. Divide en tareas atómicas. Que cada tarea del spec sea algo que un agente pueda completar y verificar sin ambigüedad. Si una tarea necesita una decisión de producto a mitad de camino, no está lista para ejecutarse; vuelve al paso 1.

4. Ejecuta con OpenCode Go. Abre OpenCode en el repo, señala el spec, y deja que el modelo obrero trabaje. Mi asignación por defecto es GLM-5.2 o Kimi K2.7 Code para la implementación principal, MiniMax M3 o DeepSeek V4 Flash para tareas mecánicas (renombrar, migrar sintaxis, generar tests repetitivos, actualizar imports).

5. Revisión con el modelo caro, solo si hace falta. Si los tests pasan y el diff es legible, no hace falta. Si algo huele raro, pásale el diff a Claude o Grok con la pregunta concreta. Son tres turnos, no treinta.

Ejemplo de spec ejecutable

# Spec: Rate limiting en el endpoint público de búsqueda

## Objetivo
Evitar abuso del endpoint `GET /api/search`, hoy sin protección.

## Contexto
- Express 4 + Redis ya disponible en `src/lib/redis.ts`
- Middleware de auth en `src/middleware/auth.ts` (patrón a imitar)
- No hay tests de middleware todavía

## Alcance
- Middleware `rateLimit` reutilizable, configurable por ruta
- Aplicarlo solo a `GET /api/search`
- Ventana deslizante en Redis, 60 peticiones / 60s por IP
- Responder 429 con header `Retry-After`

## Fuera de alcance
- Rate limiting por usuario autenticado (fase 2)
- Dashboard de métricas
- Cambios en el algoritmo de búsqueda

## Archivos
- Crear: `src/middleware/rateLimit.ts`
- Crear: `src/middleware/__tests__/rateLimit.test.ts`
- Modificar: `src/routes/search.ts` (solo añadir el middleware)

## Contrato
```ts
rateLimit(opts: { windowMs: number; max: number; keyPrefix: string }): RequestHandler

Casos borde

• Redis caído → dejar pasar la petición y loguear warning (fail-open)
• IP ausente en el request → usar req.socket.remoteAddress, y si tampoco, no limitar
• Reloj: usar Date.now() del servidor, no timestamps del cliente

Criterios de aceptación

• 60 peticiones en 60s pasan; la 61 devuelve 429
• El header Retry-After trae segundos hasta el reset
• Con Redis caído los tests siguen en verde
• npm test y npm run lint en verde
• Ningún archivo fuera de la lista de "Archivos" queda modificado

Verificación

Ejecutar npm test -- rateLimit y npm run lint.

Un spec así lo ejecuta GLM-5.2 sin despeinarse, probablemente en 25-40 turnos. A ~0,014 dólares de presupuesto Go por turno, hablamos de medio dólar de tu asignación mensual de 60. Puedes hacer esto más de cien veces al mes.

## Elegir la IA según la necesidad y la complejidad

Este es el hábito que más ahorra —dinero y frustración— y el que menos gente cultiva. La pregunta correcta antes de abrir cualquier chat no es "¿cuál es el mejor modelo?", sino "¿qué tipo de trabajo es este?".

Yo lo pienso en cuatro niveles.

**Nivel 0 — Mecánico.** Renombrar variables, convertir un formato a otro, generar boilerplate, traducir un archivo de configuración, escribir tests repetitivos a partir de un patrón ya establecido. No hay decisiones. Usa lo más barato que exista: DeepSeek V4 Flash, MiMo-V2.5, GPT 5.6 Luna. Si el resultado está mal, se nota inmediatamente y cuesta nada reintentarlo.

**Nivel 1 — Implementación guiada.** Hay un spec claro y hay que convertirlo en código que compile, pase tests y respete convenciones del proyecto. Requiere competencia real pero no juicio de producto. Aquí viven GLM-5.2, Kimi K2.7 Code, MiniMax M3, Qwen3.7 Plus. Es el 70% del trabajo real de programar y es exactamente el terreno de Go.

**Nivel 2 — Diseño acotado.** Hay que decidir algo, pero dentro de un marco conocido: cómo modelar esta tabla, qué patrón usar para este caso, cómo estructurar este módulo. Aquí sube el listón: Grok 4.5, Claude Sonnet 5, GPT 5.6 Terra. Son pocos turnos, así que aunque cuesten más, el impacto en la factura es menor de lo que temes.

**Nivel 3 — Decisión con consecuencias.** Arquitectura, estrategia de migración, elección de tecnología, análisis de un incidente confuso, cualquier cosa donde equivocarte cuesta semanas. Modelo frontera, sin dudarlo: Claude Opus 5, Claude Fable 5, GPT 5.6 Sol, Gemini 3.1 Pro. Y aquí conviene el lujo de la segunda opinión: hacer la misma pregunta a dos modelos de familias distintas y comparar. Cuando ambos coinciden, tienes una señal razonable; cuando divergen, has encontrado exactamente el punto donde tenías que pensar tú.

La regla que resume todo: **el modelo caro decide, el modelo barato ejecuta.** Y el corolario, que es igual de importante: si te encuentras usando un modelo frontera para el turno número ochenta de la misma tarea, algo salió mal en el paso de diseño. Vuelve al spec.

Hay un matiz que vale la pena explicitar, porque toca la parte filosófica de todo esto. La tentación de usar siempre el mejor modelo no es económica, es psicológica: se siente más seguro. Pero esa sensación de seguridad tiene un precio real, y no es solo el de la factura. Cuando delegas todo al modelo más capaz, dejas de distinguir entre las decisiones que importan y las que no. Forzarte a clasificar la tarea antes de elegir la herramienta es, en el fondo, un ejercicio de criterio. Y el criterio es lo único que no se puede subcontratar.

## Diez tips prácticos para exprimir el plan Go

**1. Configura tu modelo por defecto al obrero, no al caro.** En tu `opencode.json`, deja `opencode-go/glm-5.2` o `opencode-go/kimi-k2.7-code` como modelo principal. Cambiar hacia arriba debe ser un acto consciente, no el estado por defecto.

**2. Usa el sistema de agentes de OpenCode para asignar modelos por rol.** OpenCode permite definir agentes distintos con modelos distintos. Un agente `plan` con un modelo capaz que solo lee y propone, y un agente `build` con un modelo barato que ejecuta. Es el flujo de este artículo, automatizado.

**3. Escribe un `AGENTS.md` en la raíz del repo.** Convenciones, comandos de test, estructura de carpetas, qué no tocar. Cada cosa que esté ahí es una cosa que el modelo obrero no tiene que adivinar, y adivinar es lo que consume turnos.

**4. Aprovecha el caché.** El grueso del costo por turno es lectura de caché, no tokens nuevos. Sesiones largas sobre el mismo contexto son mucho más baratas por turno que abrir una sesión nueva por cada tarea pequeña. Agrupa el trabajo relacionado.

**5. Vigila el límite de cinco horas, no el mensual.** El techo que de verdad te va a morder es el de 12 dólares cada cinco horas. Si vas a hacer una sesión intensa, empieza con el modelo barato y reserva el caro para cuando se atasque.

**6. Activa "Use balance" solo si tienes saldo Zen y sabes por qué.** Es la válvula de escape: cuando agotas Go, sigue tirando de tu saldo de pago por uso en vez de bloquearse. Muy útil en un deadline, peligroso si lo dejas activo y te olvidas.

**7. Los modelos gratuitos de Zen siguen ahí cuando agotas Go.** Hay una lista de modelos en periodo gratuito (DeepSeek V4 Flash Free, MiMo-V2.5 Free, Hy3 Free, Nemotron, LongCat, entre otros). Ojo con la letra pequeña: durante el periodo gratuito los datos pueden usarse para mejorar el modelo. No los uses con código confidencial.

**8. Revisa la tabla de privacidad antes de meter código de cliente.** En Go, la mayoría de modelos tienen retención de 0 días, pero Grok 4.5 y GPT 5.6 Luna retienen 30. Si trabajas con código bajo NDA, esa columna importa más que el benchmark.

**9. Ten Zen con saldo aunque uses Go.** Diez dólares de Go más veinte de saldo Zen te da lo mejor de ambos: ejecución ilimitada en la práctica, y acceso puntual a modelos frontera cuando la decisión lo justifica. Sigue siendo menos de lo que cuesta una sola suscripción premium.

**10. Mide.** La consola de OpenCode muestra tu consumo. Míralo una vez por semana durante un mes y vas a descubrir que el 80% de tu gasto viene de dos o tres tipos de tarea. Esas son las que hay que mover a modelos baratos o, mejor, automatizar con un spec reutilizable.

## Herramientas prácticas que acompañan bien este flujo

**OpenCode** (`opencode.ai`) es la base: TUI, CLI, modo servidor, integración con IDE, soporte de MCP y de Agent Skills. Instalación de una línea, funciona en macOS, Linux y Windows vía WSL.

**El comando `/connect`** dentro de la TUI es cómo enchufas Go o Zen: te pide la API key que copias desde la consola en `opencode.ai/auth`, y con `/models` ves el catálogo disponible. En tu configuración, los IDs llevan el prefijo del proveedor: `opencode-go/kimi-k3` para Go, `opencode/gpt-5.6-sol` para Zen.

**Claude Code, Codex CLI o Grok** para la fase de diseño. Cualquiera sirve; lo que importa es que la conversación de spec ocurra en un sitio distinto al de la ejecución, aunque solo sea para no mezclar contextos.

**Un directorio `specs/` versionado en git.** Suena a poco y es la mitad del valor de este método. Los specs se acumulan, se reutilizan, se convierten en plantillas y —esto es lo bueno— se vuelven el mejor onboarding posible para cualquier persona o agente que llegue después.

**MCP servers** para dar contexto real al agente: acceso a tu base de datos, a tu gestor de tareas, a tu documentación. Un agente con contexto necesita menos turnos, y menos turnos es menos presupuesto consumido.

**Los endpoints directos de Go**, si quieres construir algo encima. `https://opencode.ai/zen/go/v1/chat/completions` es compatible con el SDK de OpenAI, y algunos modelos exponen el formato de Anthropic en `/v1/messages`. Puedes usar tu suscripción de Go desde tus propios scripts, no solo desde la TUI.

## Cuándo Go no es la respuesta

Por honestidad, tres escenarios donde yo no lo recomendaría.

Si tu trabajo es mayoritariamente de nivel 3 —consultoría de arquitectura, investigación, análisis— Go te va a servir de poco, porque el valor está en los modelos que no incluye. Paga Zen por uso y ya.

Si sois un equipo, Go no escala: solo un miembro por workspace puede suscribirse. Para equipos, el camino es un workspace de Zen con límites de gasto por miembro y modelos habilitados según el rol.

Y si tu código es confidencial de forma estricta, revisa la tabla de retención modelo por modelo y considera BYOK con un proveedor con el que ya tengas acuerdo contractual. Diez dólares es barato, pero no lo suficiente como para saltarse esa conversación.

## Cierre

La conclusión que me llevo después de meses con este flujo no es sobre OpenCode. Es sobre cómo pensamos el gasto en IA en general: seguimos comprando herramientas cuando lo que deberíamos estar diseñando son procesos.

Diez dólares al mes dan para muchísimo si la ejecución llega con instrucciones claras, y dan para bien poco si la usas como sustituto del pensamiento. El plan Go no te hace más productivo por sí solo; te obliga —por diseño, a través de sus límites— a decidir qué merece un modelo caro y qué no. Y esa disciplina, que parece una restricción, termina siendo lo que hace que el trabajo salga mejor.

Define el spec con el mejor modelo que puedas pagar. Ejecútalo con el más barato que aguante. Guarda el spec en git. Repite.

> **🎁 Empieza con $5 de crédito gratis**
> Antes de pagar el plan completo, [regístrate en OpenCode Go con este enlace](https://opencode.ai/go?ref=3CCYJM1AA3) y obtén **$5 de crédito aplicados directamente a tus límites de uso**. Es la forma más barata de probar si el flujo de este artículo encaja con tu forma de trabajar antes de comprometerte al pago mensual.

## Preguntas frecuentes

### ¿OpenCode Go reemplaza a Claude Code o a Codex?

No, y no debería. Go es un plan de ejecución con modelos abiertos. Claude Code y Codex siguen siendo mejores para la fase de diseño y para tareas que requieren juicio. El planteamiento de este artículo es usarlos juntos, no elegir.

### ¿Puedo tener Go y Zen a la vez?

Sí, y es lo que recomiendo. Go cubre la ejecución con presupuesto plano; Zen te da acceso puntual a modelos frontera. Además puedes activar la opción "Use balance" para que Go caiga a tu saldo Zen cuando agotes los límites en vez de bloquearse.

### ¿Cuántas tareas reales caben en el plan de 10 dólares?

Depende del modelo. Con GLM-5.2 (4.300 peticiones al mes) y tareas de 30 a 150 turnos, hablamos de entre 30 y 100 tareas medianas mensuales. Con DeepSeek V4 Flash, prácticamente ilimitado para uso individual.

### ¿Por qué Grok 4.5 solo da 600 peticiones al mes en Go?

Porque no todos los modelos traen el mismo presupuesto asignado. La mayoría incluye 60 dólares de uso (multiplicador 6x), pero unos pocos —Grok 4.5, Kimi K3, GPT 5.6 Luna, Qwen3.8 Max, DeepSeek V4 Pro y MiMo-V2.5-Pro— incluyen 15 (multiplicador 1.5x), porque el equipo aún no ha podido negociar descuentos sobre ellos.

### ¿Qué pasa si agoto el límite?

Puedes seguir usando los modelos gratuitos del catálogo, o activar "Use balance" para tirar de tu saldo de Zen. También puedes esperar a que se reinicie la ventana de cinco horas.

### ¿Sirve OpenCode Go para equipos?

No directamente: solo un miembro por workspace puede suscribirse. Para equipos, la vía es un workspace de Zen con roles, límites de gasto por miembro y control de qué modelos se habilitan.

### ¿Se usan mis datos para entrenar?

En los modelos de Go, no. La retención es de 0 días en casi todos, con la excepción de Grok 4.5 y GPT 5.6 Luna (30 días, por políticas de abuso de sus proveedores). Distinto es el caso de los modelos en periodo gratuito de Zen, donde los datos sí pueden usarse para mejorar el modelo.

## Sigue leyendo

Si quieres solo el precio, los límites y mi experiencia usando OpenCode Go en solitario, sin la parte de Zen ni de estrategia de specs: [OpenCode Go: precio, límites de uso y si vale la pena en 2026](/es/blogs/tecnologia/opencode-go-precio-limites-opinion).

Si te interesa el resto del panorama de proveedores de IA para programar, más allá de OpenCode: [Por qué en 2026 ya no deberías depender de un solo proveedor de IA para programar](/es/blogs/tecnologia/diversificar-proveedores-ia).

## Fuentes

- [OpenCode Go — documentación oficial](https://opencode.ai/docs/go/)
- [OpenCode Zen — documentación oficial](https://opencode.ai/docs/zen/)
- [OpenCode Go — página de producto](https://opencode.ai/go)
- [OpenCode Zen — página de producto](https://opencode.ai/zen)
- [OpenCode — documentación general](https://opencode.ai/docs/)

*Precios, modelos y límites verificados el 12 de agosto de 2026. El catálogo de OpenCode cambia con frecuencia; consulta la documentación oficial antes de tomar una decisión de compra.*