¿Cuáles son los mejores modelos para OpenCode? 7 criterios para elegir

No existe un ganador universal. Empieza con un modelo alojado y fiable para el razonamiento complejo, usa uno equilibrado para editar código a diario y elige uno local cuando la privacidad o el trabajo sin conexión sean prioritarios. Los modelos gratuitos o incluidos sirven para probar un flujo, pero no garantizan la misma calidad para siempre. Esta guía convierte la elección en una comprobación repetible.

Un modelo excelente para planificar arquitectura puede ser innecesario para un cambio pequeño. Separa el trabajo en razonamiento y planificación, implementación, documentación y transformaciones rápidas. La planificación necesita coherencia en varios pasos; la implementación necesita editar archivos con precisión; la documentación valora claridad y velocidad; una transformación simple no debería consumir el modelo más caro.

Para elegir los mejores modelos para OpenCode, anota la salida esperada, el coste de equivocarse, el contexto del repositorio y si habrá llamadas a herramientas. Una explicación de solo lectura puede empezar con un modelo rápido. Una migración que modifica muchos archivos merece un modelo más fuerte y un diff revisado por una persona. Así el criterio sigue siendo válido aunque cambie el catálogo.

No uses mejor modelo como sustituto de un requisito. En ediciones repetitivas puede importar más la latencia; en una incidencia de producción importan la fiabilidad y la trazabilidad. El flujo de las próximas secciones hace explícita esa decisión.

Los modelos alojados suelen ser el primer punto de referencia porque el proveedor gestiona el entorno. Encajan cuando necesitas razonamiento, contexto o herramientas estables, pero implican red, políticas y coste. Antes de enviar código privado, revisa el proveedor y su tratamiento de datos.

Un modelo local depende de memoria, cómputo, cuantización, runtime y uso de herramientas; no es simplemente un modelo alojado barato. Puede ser ideal para privacidad u offline, aunque suele necesitar prompts más pequeños. Elige la ruta local solo después de comprobar el hardware y consulta la guía de Ollama para la conexión.

Un plan o suscripción puede simplificar la facturación, pero sus cuotas, modelos disponibles y límites también cambian. Separa la comparación de planes de la capacidad real del modelo.

Más contexto no siempre significa una respuesta mejor: todo el repositorio puede añadir ruido y coste. Empieza con los archivos mínimos que prueban la tarea y amplía solo cuando falten evidencias. Comprueba qué puede leer el agente y qué herramientas están activas.

La latencia importa en un terminal interactivo. La fiabilidad incluye formato consistente, selección correcta de herramientas, reconocimiento de límites y fallos previsibles. La privacidad es una restricción del proyecto, no un adjetivo de marketing. Decide qué código puede salir del equipo antes de elegir el proveedor.

Usa el mismo prompt, contexto y tarea con cada candidato. Anota el tiempo hasta una respuesta útil, los errores, los archivos modificados y la cantidad de correcciones. Guarda el identificador y la fecha del modelo para que la decisión pueda auditarse.

La configuración de modelos de OpenCode usa el patrón provider/model. El identificador exacto debe verificarse en la documentación actual del proveedor. Mantén el valor en el alcance adecuado, y deja las credenciales en el flujo del proveedor o en variables de entorno.

Una configuración mínima es más fácil de revisar que un catálogo copiado. Prueba primero una tarea de bajo riesgo y documenta por qué el modelo encaja. La documentación oficial de modelos y configuración es la referencia para el esquema.

{
  "$schema": "https://opencode.ai/config.json",
  "model": "provider/model-id"
}

No evalúes un modelo con una demostración ingeniosa. Usa una tarea real: explicar un módulo, proponer un plan, implementar un cambio limitado y revisar el diff. Mantén iguales el repositorio, el prompt y los criterios.

Registra corrección, completitud, coste de interacción y riesgo. Incluye tiempo de espera, preguntas de seguimiento, comandos no autorizados y archivos inesperados. Una respuesta convincente que omite una restricción no debe ser el valor predeterminado.

Cambia solo cuando el patrón de fallo se repita. Reduce contexto si fallan las tareas largas, revisa permisos si fallan las herramientas y prueba un modelo local más pequeño si el problema es la velocidad.

1. Fijar la tareaUsa una tarea, snapshot, prompt y lista de aceptación.
2. Empezar en solo lecturaPide supuestos y plan antes de permitir cambios.
3. MedirRegistra tiempo útil, errores, preguntas y archivos.
4. Revisar el diffRechaza cambios sin explicación o sin pruebas.
5. Elegir el valor predeterminadoConserva el modelo que supera el umbral con menor riesgo práctico.

Un ranking puede usar otros prompts, herramientas, contextos y fechas. Trátalo como una hipótesis y compruébalo con un benchmark pequeño del repositorio.

Los modelos gratuitos ayudan a aprender, pero sus cuotas, colas, contexto y disponibilidad pueden ser distintos. Úsalos en tareas de bajo riesgo hasta que superen la misma prueba que el candidato de producción.

Antes de cambiar de modelo, comprueba provider, identificador, autenticación, permisos y configuración activa. Un modelo que parece fallar puede estar recibiendo un ID incorrecto o un contexto excesivo.

Los catálogos cambian más rápido que el proceso del repositorio. Conserva el tipo de tarea, el límite de contexto, las comprobaciones y la reversión; actualiza el ID y las mediciones cuando cambie el proveedor. No prometas que un modelo será siempre el mejor.

Para continuar, usa la guía de Ollama para modelos locales, la comparación Go y Zen para planes, JSONC para estructura y MCP para herramientas y permisos. Esta página es la capa que decide qué ruta probar primero.