Luna, Terra y Sol: elegir el modelo adecuado para cada tarea
En los últimos días he estado pensando en una pregunta muy práctica: cuando utilizo ChatGPT, Work, Codex u OpenClaw, ¿qué modelo debería escoger en cada situación? No se trata simplemente de elegir siempre el más potente. La decisión depende de tres cosas: la dificultad del trabajo, el grado de autonomía que le voy a conceder al agente y el coste de equivocarse.
La regla general es bastante sencilla: Luna para ejecutar y mantener, Terra como modelo de trabajo habitual y Sol para los problemas complejos o de alto impacto. Esta división permite aprovechar mejor los modelos y evitar gastar capacidad —y dinero— donde no hace falta.
La regla práctica: dificultad, autonomía y coste del error
Una pregunta sencilla, una tarea repetitiva o una transformación bien definida no necesitan el mismo razonamiento que una investigación abierta o una intervención delicada en un servidor. Tampoco es igual pedir código para revisar tranquilamente que dejar al agente actuar sobre un VPS, una cuenta, una partida o un sistema que debe seguir funcionando.
Por eso conviene valorar:
- La dificultad: ¿hay una respuesta clara o hace falta investigar, comparar alternativas y razonar mucho?
- La autonomía: ¿el modelo sólo redacta una respuesta o también observa el estado, decide los siguientes pasos y utiliza herramientas?
- El coste del error: ¿un fallo se corrige fácilmente o puede borrar datos, romper un servicio, gastar recursos o tomar una mala decisión estratégica?
Cuando las tres variables son bajas, Luna suele ser suficiente. Cuando son medias, Terra ofrece el mejor equilibrio. Cuando alguna de ellas es alta, especialmente el coste del error, merece la pena utilizar Sol.
Luna: ejecución, rutina y volumen
Luna es el modelo que elegiría para las tareas frecuentes, previsibles y relativamente mecánicas. Su ventaja no es sólo que pueda resolverlas, sino que permite reservar los modelos más caros y capaces para aquello que realmente lo necesita.
En conversación cotidiana puede servir para resumir textos, reformular mensajes, ordenar ideas, convertir notas en listas, extraer datos de documentos o responder preguntas cuya dificultad sea moderada. También es adecuado para mantener una memoria personal, clasificar información y preparar borradores.
En OpenClaw encaja especialmente bien con crones y automatizaciones: generar un boletín a partir de fuentes ya seleccionadas, revisar periódicamente un servicio, mover archivos, comprobar si hay novedades, preparar informes rutinarios o ejecutar una secuencia de pasos que ya está bien definida. En este tipo de tareas el volumen importa mucho y Luna puede ofrecer una relación coste-resultado muy buena.
También lo utilizaría para mantenimiento sencillo de una web, pequeños cambios en un plugin de Obsidian, ajustes de formato, documentación básica o correcciones obvias. Si el objetivo está claro y el agente no tiene que tomar decisiones delicadas, no hace falta complicarlo más.
Terra: el modelo de trabajo habitual
Terra sería mi elección por defecto para la mayor parte del trabajo serio del día a día. Es el punto de equilibrio entre capacidad, velocidad, coste y autonomía. Tiene margen suficiente para entender contexto, investigar, planificar varios pasos y utilizar herramientas sin convertir cada tarea en una operación costosa.
Para investigación puede localizar información, contrastar fuentes, resumirla y convertirla en una explicación útil. En teología, historia o cuestiones intelectuales permite mantener una conversación más matizada, comparar interpretaciones y señalar dudas sin tener que recurrir siempre al modelo máximo.
En diseño y desarrollo web lo usaría para crear una página, organizar su arquitectura, proponer una interfaz, escribir componentes, conectar servicios y hacer iteraciones. Para un proyecto nuevo puede ser el modelo principal, dejando Sol para las decisiones de arquitectura especialmente difíciles o para los errores que se resistan.
En OpenClaw, Terra es adecuado cuando el agente debe coordinar varias fuentes, recordar un objetivo, escoger entre distintas acciones y devolver un resultado estructurado. También es una buena opción para diseñar automatizaciones nuevas antes de pasarlas a Luna para su ejecución repetitiva.
Sol: problemas complejos y de alto impacto
Sol lo reservaría para las situaciones en las que la calidad de las decisiones importa más que el coste o la velocidad. No significa que haya que usarlo para todo, sino que conviene tenerlo disponible cuando el problema exige un análisis profundo, una planificación cuidadosa o una gran capacidad de depuración.
En una investigación difícil puede ayudar a formular mejores preguntas, comparar evidencias, detectar contradicciones y construir una conclusión bien argumentada. En teología o en cualquier tema con muchas interpretaciones, es especialmente útil cuando no basta con resumir y hace falta distinguir conceptos, supuestos y consecuencias.
En programación lo elegiría para debugging complicado, refactorizaciones grandes, cambios que afectan a varias partes del sistema, problemas de arquitectura, migraciones y situaciones en las que un error puede introducir una cadena de fallos. También es el candidato natural para crear desde cero una aplicación ambiciosa o para revisar críticamente una solución propuesta por otro modelo.
Casos concretos de mi uso
OGame con control del navegador
Gestionar una partida de OGame combina dos trabajos distintos. La parte mecánica —revisar planetas, comprobar recursos, construir algo, moverme por los menús o lanzar una acción ya decidida— puede hacerla Luna.
La parte estratégica es diferente: interpretar el estado de la cuenta, decidir qué conviene priorizar, coordinar recursos y flotas, mantener objetivos a medio plazo y reaccionar ante cambios. Para eso Terra es una opción más equilibrada. Sol tendría sentido en una situación especialmente compleja, con muchas restricciones, decisiones irreversibles o un coste alto por equivocarse.
Administración de un VPS por SSH
Para comprobar espacio, consultar registros conocidos, reiniciar un servicio concreto o ejecutar una tarea documentada, Luna puede bastar siempre que los permisos y las instrucciones estén bien limitados.
Terra sería preferible para mantenimiento general, investigar por qué un servicio no responde, revisar una instalación o coordinar varias comprobaciones. Sol lo reservaría para migraciones, problemas de seguridad, pérdida de datos, cambios de infraestructura o cualquier operación en la que una orden equivocada pueda dejar el VPS fuera de servicio.
La autonomía cambia completamente el cálculo: cuando el modelo sólo sugiere comandos, el usuario puede revisar; cuando el agente los ejecuta directamente, la elección de un modelo más cuidadoso puede estar justificada.
Diseño y desarrollo web
Luna es suficiente para cambios pequeños, textos, estilos, componentes aislados o mantenimiento rutinario. Terra es el modelo natural para diseñar y construir una web completa: entender el objetivo, proponer la estructura, implementar las páginas y ajustar la experiencia de usuario.
Sol aporta valor cuando hay que resolver una arquitectura compleja, integrar muchos servicios, depurar errores difíciles o tomar decisiones que condicionarán todo el proyecto. También lo usaría en la primera fase de una aplicación importante, para establecer una base sólida, y después pasaría el mantenimiento normal a Terra o Luna.
Plugins de Obsidian
Para modificar un plugin pequeño, cambiar una opción, ajustar una interfaz o corregir un error evidente, Luna puede hacerlo. Terra es mejor cuando hay que entender el funcionamiento del plugin, respetar sus convenciones y tocar varias piezas sin romper la compatibilidad.
Sol queda para refactorizaciones profundas, problemas de rendimiento, errores intermitentes, cambios de API o plugins cuyo código sea difícil de comprender. Como Obsidian se ha convertido en mi memoria personal conectada a la IA, aquí el coste de introducir cambios silenciosos también merece atención: no sólo importa que compile, sino que siga conservando y mostrando correctamente la información.
Automatizaciones y OpenClaw
OpenClaw es probablemente el caso en el que más importa distinguir entre inteligencia y autonomía. Un modelo puede ser capaz de escribir código y, sin embargo, no ser la mejor elección para un agente que toma decisiones, usa herramientas, conserva contexto y se ejecuta sin supervisión constante.
Usaría Luna para boletines, comprobaciones periódicas, sincronizaciones, clasificación y tareas con entradas y salidas muy definidas. Terra lo usaría para crear y revisar los flujos, investigar cuando una automatización falla y coordinar varias herramientas. Sol lo reservaría para diseñar agentes importantes, depurar comportamientos extraños, analizar permisos o revisar automatizaciones que puedan tener consecuencias externas.
La estrategia más sensata es construir con Terra o Sol, probar con supervisión y ejecutar después con Luna cuando el flujo esté estabilizado. Así se paga la capacidad máxima durante el diseño, no durante cada repetición.
ChatGPT, Work y Codex
En conversación directa, ChatGPT es el espacio más natural para pensar, investigar, redactar y discutir ideas. Terra puede ser el compañero habitual; Luna sirve para consultas rápidas y tareas de mucho volumen; Sol queda para análisis complejos, decisiones importantes y problemas que requieren una segunda marcha.
Work y Codex tienen más sentido cuando el trabajo se apoya en archivos, carpetas, repositorios, terminales o herramientas. Ahí no sólo importa la respuesta final: importa que el modelo sepa orientarse, inspeccionar el contexto, actuar en el entorno y verificar lo que ha hecho. Para un cambio trivial, Luna puede ahorrar tiempo y coste. Para un proyecto real, Terra suele ser el punto de partida. Para una operación delicada o un debugging difícil, Sol puede compensar ampliamente la diferencia.
Una configuración razonable
Mi configuración mental quedaría así:
- Empiezo por Luna si la tarea es repetitiva, reversible y está bien especificada.
- Subo a Terra si hay que investigar, coordinar herramientas, tomar decisiones o trabajar con un contexto amplio.
- Elijo Sol si el problema es difícil, el agente tiene mucha autonomía o el coste de equivocarse es alto.
- Vuelvo a Luna cuando el trabajo ya está entendido y convertido en un procedimiento estable.
La clave es no confundir el modelo más caro con el modelo más adecuado. Un modelo potente puede ser innecesario para una tarea rutinaria, mientras que ahorrar demasiado en una operación crítica puede salir caro. La elección correcta es la que ajusta la capacidad al riesgo real.
Para mi uso concreto, Terra sería el modelo principal de trabajo; Luna, el motor de ejecución y mantenimiento; y Sol, el especialista para los momentos en los que necesito profundidad, autonomía fiable o máxima atención. Esa combinación ofrece algo más valioso que utilizar siempre el mismo modelo: una forma de trabajar sostenible, flexible y adaptada a cada problema.
