Durante años, manejé mis sitios WordPress con OpenLiteSpeed. Un servidor rápido, LSCache es genuinamente impresionante, y el combo OLS/WordPress es difícil de superar en rendimiento bruto. Para el panel de control, empecé con CyberPanel — más buggy que un producto de Microsoft, con un equipo que parece estar saboteando deliberadamente sus funciones gratuitas para empujar a los usuarios hacia planes pagos. No hablo de bugs que no se pueden arreglar. Hablo de bugs que parecen diseñados para impedir que las funciones gratuitas completen cualquier acción.
Dos ejemplos. Instalación de WordPress: la usé durante años sin problemas. Desde CyberPanel v2.4.x, un error de SQL bloquea el paso final. Los archivos están ahí, completamente descargados, pero tienes que crear la base de datos manualmente y ejecutar la instalación tú mismo. Contraintuitivo, por decir lo menos.
Segundo ejemplo: la generación de certificados SSL Let’s Encrypt falla sistemáticamente porque los archivos de configuración generados son incorrectos. Y en ambos casos, existe una versión “mejorada” de pago. Naturalmente.
Mi postura es simple: si una función funcionó durante años y ahora no funciona, no tengo garantía de que la versión de pago funcione tampoco — o de que los términos no cambien mañana. ¿Es una trampa de cebo y cambio? No lo diré explícitamente. Pero cuando una función gratuita funciona durante años, luego deja de funcionar en múltiples versiones consecutivas, y existe una alternativa de pago que cubre el mismo terreno — la pregunta se responde sola.
Así que migré a aaPanel: más agradable, más estable, más ligero. Pero con un enfoque completamente fuera de control para la gestión de OLS — no puedes configurar OpenLiteSpeed directamente, todo pasa por la capa de abstracción de aaPanel, y pierdes el control de tu propio stack. Tocar el puerto 7080 directamente y corres el riesgo de romper todo. Usas el panel de aaPanel. Punto.
Luego mi uso cambió. Más Astro, más sitios cuasi-estáticos, más proyectos donde PHP no es necesario. OLS pierde su atractivo en cuanto sales del perímetro de WordPress. Caddy, por otro lado, maneja HTTPS automáticamente, su configuración cabe en unas pocas líneas legibles, y no tiene las rarezas de reescritura de OLS.
La pregunta se volvió: ¿puedes reemplazar aaPanel/OLS con Caddy y un panel de control? Existe uno en GitHub — CaddyManager, 1.1k estrellas, un solo contribuyente, perpetuamente en “desarrollo temprano”. También está CaddyGen, un generador de Caddyfile construido en 8 horas — más prueba de concepto que producto terminado. Nada listo para producción.
La conclusión fue obvia: scripts de shell bien escritos y una interfaz mínima con FastAPI harían el trabajo — y serían infinitamente más mantenibles. Alguien solo tenía que escribirlos.
En lugar de hacerlo yo mismo, pensé en entregar una especificación a GitHub Copilot CLI. O Claude Code. Pero dado el nuevo precio de Copilot, que apenas te deja mojar los labios antes de que llegue la factura… me interesé en OpenCode y Kilo CLI, conectados a DeepInfra u OpenRouter. Y decidí convertirlo en un benchmark.
“El precio de un modelo no predice la calidad de su producción en tareas complejas. El modelo menos glamoroso del benchmark dominó la competencia.”
1. El proyecto de prueba
El brief fue deliberadamente concreto: un toolkit mínimo de administración de VPS para Ubuntu 24.04. Caddy como servidor web, PHP-FPM en dos versiones (actual y fallback), MariaDB y PostgreSQL, Valkey para caché de objetos. Scripts de shell para todas las operaciones, una interfaz FastAPI para automatización. Sin Docker, sin panel de control, sin abstracción innecesaria.
Cuatro tipos de sitio: estático (HTML/assets solamente, sin PHP, sin base de datos), PHP (apps personalizadas, base de datos opcional), WordPress (instalación completa vía WP-CLI, base de datos requerida), y proxy inverso. Este último merece una nota: es simplemente un vhost de Caddy que reenvía peticiones a un puerto local — una aplicación Node.js, FastAPI o Go corriendo en el mismo servidor. Caddy maneja HTTPS y el dominio; la aplicación no necesita preocuparse. Sin PHP-FPM, sin base de datos — solo un bloque reverse_proxy y un número de puerto.
Las operaciones esperadas cubren el ciclo de vida completo: bootstrap del servidor, aprovisionamiento de sitios, eliminación con backup automático antes de cualquier operación destructiva, creación de bases de datos bajo demanda, despliegue estático vía rsync, backup y gestión de servicios.
¿Por qué un proyecto real en lugar de un benchmark sintético? Porque los benchmarks sintéticos prueban lo que los modelos pueden hacer en condiciones ideales. Un proyecto real prueba lo que hacen cuando las restricciones se acumulan — seguridad, idempotencia, consistencia entre archivos, manejo de errores entre capas de shell y Python. Ahí es donde surgen las diferencias.
2. Metodología
El protocolo se ejecuta en dos fases distintas, separadas por validación humana.
Fase 1 — Arquitectura
Se entrega un brief funcional idéntico a cada combinación herramienta/modelo. Sin contexto adicional, sin archivos de configuración, sin pistas sobre la solución esperada. La herramienta propone una arquitectura, una estructura de proyecto, una lista de scripts con sus responsabilidades, un mapa de rutas API. Y si está bien diseñada, hace preguntas antes de producir cualquier cosa.
Fase 2 — Implementación
Una vez validado el plan y tomadas las decisiones, se envía un solo prompt de desarrollo a todas las herramientas. Incluye la arquitectura validada, las diez decisiones técnicas confirmadas, la convención de códigos de salida script→API, y una instrucción inequívoca: entregar treinta archivos en disco, en orden, sin resúmenes, sin atajos.
Combinaciones probadas
| Herramienta | Modelo |
|---|---|
| Claude Code | Haiku 4.5 |
| Copilot CLI | Haiku 4.5 |
| OpenCode | Haiku 4.5 |
| OpenCode | GLM 5.2 |
| OpenCode | BigPickle (gratis) |
| OpenCode | Gemini 3.1 Pro |
| OpenCode | DeepSeek V4 Pro |
| OpenCode | GPT-OSS-120B |
Haiku 4.5 aparece tres veces — en tres herramientas diferentes. Esto es deliberado: permite aislar el impacto de la herramienta independientemente del modelo.
Revisión externa
El código producido por las cuatro implementaciones seleccionadas fue enviado a un modelo ausente del benchmark, con una grilla de evaluación fija: seguridad, corrección, idempotencia, calidad de código, completitud. Cinco archivos representativos por implementación, puntuados sobre 25.
3. Fase de planificación — ¿quién piensa realmente?
El brief funcional plantea una pregunta implícita a cada herramienta: ¿qué haces cuando recibes un proyecto abierto sin solución predefinida?
Lo primero que se nota — y es impactante — es que ninguno de los modelos probados hace preguntas antes de producir un plan. Ni uno. Todos entregan una arquitectura completa primero, y luego piden aclaraciones al final. Es lo inverso de lo que haría un arquitecto humano, que se detiene en las ambigüedades antes de dibujar cualquier cosa.
Esto importa. Varias preguntas planteadas después del hecho habrían cambiado decisiones arquitectónicas si se hubieran hecho desde el principio. Un modelo identifica la tensión entre “sin secretos en disco” y archivos de configuración de aplicaciones que legítimamente necesitan credenciales — wp-config.php siendo el ejemplo obvio. Esa es una pregunta genuinamente bloqueante. Planteada después del plan, se convierte en una nota al pie.
Lo que revelan los planes
La calidad de las preguntas es la primera señal discriminante. Dos modelos hacen las cuatro o cinco preguntas genuinamente bloqueantes, enmarcadas con opciones y recomendaciones. Otro hace ocho preguntas genéricas — formato de archivo, rotación de logs — que no habrían cambiado nada arquitectónicamente.
La estructura propuesta es la segunda señal. Solo un modelo propone espontáneamente un punto de entrada CLI unificado — bin/vpsmgr — que despacha a los scripts. Es el detalle que convierte una colección de scripts en una herramienta coherente. Los otros no lo pensaron.
Un modelo es el único que propone una convención de códigos de salida normalizada y documentada desde la fase de planificación:
| Código | Significado | HTTP |
|---|---|---|
| 0 | Éxito | 200 |
| 1 | Entrada inválida | 400 |
| 2 | No encontrado | 404 |
| 3 | Conflicto | 409 |
| 4 | Dependencia faltante | 422 |
| 5 | Error interno | 500 |
Esto no es cosmético. Es el contrato entre los scripts de shell y la capa FastAPI — sin él, el mapeo HTTP se vuelve arbitrario y cada ruta lo implementa de forma diferente.
Costos de la fase de planificación
| Herramienta + Modelo | Tokens | Costo |
|---|---|---|
| BigPickle | ~35k | $0 |
| GPT-OSS-120B | 20k | $0.003 |
| DeepSeek V4 Pro | 31k | $0.044 |
| GLM 5.2 | 43k | $0.06 |
| Copilot + Haiku 4.5 | ~60k | $0.07 |
| Haiku 4.5 (OpenCode) | 69k | $0.076 |
| Gemini 3.1 Pro | 27k | $0.095 |
| Claude Code + Haiku | — | Suscripción Pro |
Gemini 3.1 Pro produce el output más conciso — 27k tokens para un plan de calidad. Haiku 4.5 en OpenCode consume 69k tokens para menor calidad. El volumen de tokens no predice la calidad.
4. Fase de código — ¿quién entrega realmente?
La fase de código comienza con un único prompt de desarrollo, enviado a las cuatro implementaciones seleccionadas. Incluye la arquitectura validada, las diez decisiones técnicas confirmadas, la convención de códigos de salida, y una instrucción inequívoca: entregar treinta archivos en disco, en orden de dependencias, sin resúmenes, sin atajos.
Aquí es donde las diferencias entre modelos se vuelven concretas.
Lo que revela common.sh
La biblioteca compartida es el primer archivo entregado. Es la base sobre la que descansa todo lo demás — logging, manejo de secretos, gestión de estado del sitio, generación de contraseñas. Un common.sh defectuoso contamina cada script que lo importa.
Modelo A entrega 98 líneas concisas. La redacción de secretos cubre explícitamente los diez patrones de WordPress — salts, claves de autenticación. El más completo en este punto específico. Sin validación de dominio, sin require_cmd(), sin escrituras atómicas de archivos de estado.
Modelo B entrega 310 líneas. Constantes nombradas con readonly, normalize_domain() con regex RFC-1035, bloqueos de concurrencia, escrituras atómicas con mktemp+mv. La biblioteca de utilidades del sistema más rica. Pero la redacción de secretos omite los salts de WordPress.
Modelo C entrega 366 líneas. Los patrones de redacción son configurables vía variable de entorno — no hardcodeados. Helpers JSON en shell puro con fallback a Python si jq está ausente. print_credentials() envolviendo output en marcadores > como se especificó en el prompt. render_template() para archivos de configuración, sin dependencia de Jinja. Generación de contraseñas excluyendo caracteres ambiguos (0/O/1/l/I). La única implementación que anticipa cada caso borde documentado en el prompt de desarrollo.
Modelo D entrega 184 líneas. La idea más original del benchmark: códigos de salida encapsulados en funciones nombradas — exit_input_error(), exit_conflict() — más legibles que exit 3 desnudo. Y json_output() directamente en common.sh, generando JSON listo para API desde shell. Sin escrituras atómicas, sin require_cmd().
“El modelo C (GLM 5.2) fue el único que probó su propio código durante la sesión, encontró dos bugs y los corrigió inmediatamente antes de entregar.”
Los bugs que encuentras tú mismo — o no
El Modelo C prueba su propio código durante la sesión. Después de escribir schemas.py, lo ejecuta con casos de prueba, encuentra dos bugs y los corrige inmediatamente: un validador de Pydantic v2 implementado incorrectamente (field_validator en lugar de model_validator para validación entre campos), y una exclusión mutua no aplicada a nivel de esquema. También corrige un problema de sustitución de sed en render_template() — roto con / en rutas — reemplazado con expansión de parámetros de bash puro.
Al final de su sesión, el Modelo C entrega un resumen de verificación: bash -n en todos los scripts, AST de Python en todos los archivos, 19/19 rutas API verificadas vía especificación OpenAPI, 18/18 helpers de bash probados, regla de fallback de PHP verificada (8.5→8.4, 8.4→ninguno, 7.x rechazado).
El Modelo A verifica sus shebangs antes de terminar. El Modelo B entrega documentación de usuario pulida — troubleshooting, ejemplos de curl, inicio rápido. El Modelo D valida sintaxis de bash y Python. Ninguno de los tres prueba lógica funcional.
Costos de la fase de código
| Modelo | Tokens | Tiempo | Costo código | Total |
|---|---|---|---|---|
| A (BigPickle) | — | 2m58s | $0 | $0 |
| D (DeepSeek V4 Pro) | 1.29M | 9m42s | ~$0.19 | $0.24 |
| B (Claude + Haiku) | — | ~15m | Suscripción Pro | $20/mes |
| C (GLM 5.2) | 4.42M | 23m37s | $1.67 | $1.73 |
5. Revisión externa — y la revelación
Cuatro implementaciones, cuatro enfoques de seguridad. Para resolverlo sin sesgo, la revisión de código se entregó a un modelo ausente del benchmark, con una grilla fija de cinco criterios. Cinco archivos representativos por implementación — common.sh, site-create.sh, site-delete.sh, backup.sh, api/runner.py — veinte archivos cargados en una sola pasada.
Costo de la revisión: $0.0766 por 543k tokens. Diez veces más barato que una hora de un desarrollador junior.
El veredicto
| Criterio | A (BigPickle) | B (Claude+Haiku) | C (GLM 5.2) | D (DeepSeek V4) |
|---|---|---|---|---|
| Seguridad | 3/5 | 3/5 | 5/5 | 2/5 |
| Corrección | 3/5 | 2/5 | 5/5 | 2/5 |
| Idempotencia | 3/5 | 3/5 | 5/5 | 3/5 |
| Calidad código | 3/5 | 2/5 | 5/5 | 3/5 |
| Completitud | 3/5 | 2/5 | 5/5 | 2/5 |
| Total | 15/25 | 12/25 | 25/25 | 12/25 |
Listo para producción tal cual: uno de cuatro. Modelo C, 25/25.
La revelación
| Alias | Modelo | Herramienta | Costo total |
|---|---|---|---|
| A | BigPickle | OpenCode | $0 |
| B | Haiku 4.5 | Claude Code | Suscripción Pro |
| C | GLM 5.2 | OpenCode | $1.73 |
| D | DeepSeek V4 Pro | OpenCode | $0.24 |
El Modelo B — Claude Code + Haiku 4.5 — es el más caro en costo marginal real, con una suscripción Pro de $20/mes como mínimo. Obtiene 12/25 y no es desplegable debido a bugs fundamentales de bash. El Modelo C — GLM 5.2, del laboratorio THUDM de la Universidad Tsinghua — obtiene 25/25 y es el único que el revisor considera listo para producción. Costó $1.73.
Addendum — Kimi K2.7 Code
Añadido después de la publicación tras un comentario de un lector. Mismo protocolo, mismo prompt de desarrollo, misma grilla de revisión Qwen 3.7 Plus.
| Alias | Modelo | Herramienta | Costo total |
|---|---|---|---|
| E | Kimi K2.7 Code | OpenCode | $0.859 |
Puntaje revisión externa: 19/25
| Criterio | E |
|---|---|
| Seguridad | 3/5 |
| Corrección | 4/5 |
| Idempotencia | 4/5 |
| Calidad código | 4/5 |
| Completitud | 4/5 |
Listo para producción: No. Problema bloqueante: las contraseñas de bases de datos se pasan inline como argumentos a mysql -e y psql -c — visibles en /proc/*/cmdline para cualquier usuario del sistema.
Addendum 2 — Validación multi-revisor
Siguiendo una sugerencia de un lector, la revisión ciega se extendió a dos modelos adicionales: GPT-5.3 Codex y Gemini 3.1 Pro Preview. Mismo protocolo, mismos cinco archivos por implementación, misma grilla de puntuación.
Puntajes comparativos
| Modelo | Qwen 3.7 Plus | GPT Codex | Gemini 3.1 Pro | Producción |
|---|---|---|---|---|
| A (BigPickle) | 15/25 | 13/25 | 11/25 | No (3/3) |
| B (Claude+Haiku) | 12/25 | 12/25 | 18/25 | No (3/3) |
| C (GLM 5.2) | 25/25 | 17/25 | 25/25 | Sí (2/3) |
| D (DeepSeek V4) | 12/25 | 14/25 | 14/25 | No (3/3) |
| E (Kimi K2.7) | 19/25 | 13/25 | 21/25 | Condicional (1/3) |
El ranking C > E > D > A > B se mantiene entre los tres revisores — el resultado original es estable.
6. Enrutamiento inteligente — la economía real
Este benchmark plantea una pregunta implícita: ¿necesitas GLM 5.2 para todo?
No. Y esa es probablemente la conclusión más útil del ejercicio.
GLM 5.2 a $1.40/M tokens es la elección correcta cuando la complejidad lo justifica — arquitectura, seguridad, consistencia entre archivos, decisiones críticas. Pero en un proyecto real, esas tareas representan una fracción de las interacciones. El resto es boilerplate, correcciones menores, documentación, mensajes de commit.
Tres niveles, tres modelos
BigPickle obtiene 15/25 en una implementación completa de 32 archivos. Es perfectamente capaz de leer 50 líneas de diff y escribir un mensaje de commit adecuado. De depurar un 1064 You have an error in your SQL syntax o un Fatal error: Call to undefined function. De generar un README a partir de código existente. Para estas tareas, la profundidad arquitectónica de GLM 5.2 es excesiva — y BigPickle es gratis.
DeepSeek V4 Pro a $0.44/M tokens — cinco veces más barato que Haiku 4.5 y tres o cuatro veces más barato que GLM 5.2 — maneja cómodamente generación de código simple, CRUD, refactorización menor, documentación inline, scripts cortos.
GLM 5.2 entra cuando la complejidad supera ese alcance — diseño de arquitectura, implementación coherente multi-archivo, decisiones de seguridad, lógica de negocio no trivial.
| Nivel | Modelo | Costo | Usos típicos |
|---|---|---|---|
| Gratis | BigPickle | $0 | Debug, commits, preguntas rápidas, errores SQL |
| Económico | DeepSeek V4 Pro | $0.44/M | Boilerplate, CRUD, documentación, scripts cortos |
| Premium | GLM 5.2 | $1.40/M | Arquitectura, seguridad, consistencia multi-archivo |
“El enrutamiento inteligente consiste en reservar GLM 5.2 para las tareas que justifican su contexto largo — y pasar todo lo demás a los dos niveles inferiores.”
La comparación incómoda
GitHub cambió a facturación por tokens el 1 de junio de 2026. Claude Sonnet 4.6 en Copilot se cobra a aproximadamente $3.00/M tokens de entrada y $15.00/M de salida. Reproducir la sesión de GLM 5.2 de este benchmark — 4.46M tokens — costaría un estimado de $25 en Copilot + Sonnet 4.6. Sin las pruebas funcionales. Sin la autocorrección. Sin la revisión externa.
La proporción final: $1.94 todo incluido vs ~$25 en Copilot + Sonnet. Trece veces más barato, para el único resultado que el revisor externo considera listo para producción.
Conclusión
$1.94. Eso es lo que costó este benchmark de principio a fin — planificación, implementación, revisión externa incluida. Para el único toolkit que el revisor considera listo para producción.
Esa cifra es incómoda para el mercado de herramientas de codificación con IA, que vende tranquilidad a través del precio. Copilot Pro+ a $39/mes, Claude Sonnet a $15/M tokens de salida, los grandes nombres al frente y al centro — la suposición implícita es que la calidad sigue al precio. Este benchmark sugiere lo contrario.
El ganador se llama GLM 5.2. Su laboratorio, THUDM, es parte de la Universidad Tsinghua. Probablemente no lo viste en las comparaciones de la semana pasada. Produjo la única arquitectura con una convención de códigos de salida normalizada desde la fase de planificación, la única implementación que prueba su propio código durante la sesión, el único common.sh con redacción configurable y fallback a Python si jq está ausente. Y corrigió tres bugs antes de entregar.
Dos conclusiones.
Primero: el precio de un modelo no predice la calidad de su producción en tareas complejas. Haiku 4.5 en tres herramientas diferentes — Claude Code, Copilot CLI, OpenCode — produce resultados idénticos por costo idéntico. En la fase de planificación — generación de texto puro, sin bucle de retroalimentación, sin exploración de código — la herramienta no tiene impacto medible. Lo que importa es el modelo. Y el modelo menos glamoroso del benchmark domina.
Segundo: no todos los tokens son iguales. Una fase de planificación a $0.06, una fase de código a $1.67 — eso es un factor de 28. No es una anomalía, es la estructura del problema. Un plan son unos pocos miles de tokens de razonamiento. Una implementación son millones de tokens de contexto acumulado, código ejecutado, pruebas iteradas. Enrutar inteligentemente entre BigPickle a $0, DeepSeek V4 Pro a $0.44/M, y GLM 5.2 a $1.40/M según la complejidad de la tarea — esa es la economía real de estas herramientas.
El toolkit VPS Manager está disponible en GitHub en sus cuatro versiones. Los briefs, prompts y grilla de evaluación también están allí. Reproducible, si quieres verificarlo.
¿Demasiado barato para ser bueno? Esa era la pregunta equivocada.