Cómo migraron un agente de IA en producción a GPT-5.6 y lograron que fuera 2.2 veces más rápido y 27% más barato

 (ploy.ai)
2 puntos por GN⁺ 1 일 전 | 1 comentarios | Compartir por WhatsApp
  • Ploy cambió el agente que planifica, construye y valida sitios web de marketing en producción de Claude Opus 4.8 a GPT-5.6 Sol y lo estableció como modelo predeterminado para todos los workspaces
  • Tras corregir las suposiciones por modelo en el harness de evaluación, el tiempo promedio de ejecución en la tarea de reconstrucción de la página principal se redujo de 8 minutos a 3 minutos 42 segundos, el costo bajó 27% de $3.06 a $2.22 y la puntuación visual subió a 0.970
  • GPT-5.6 llenaba con valores arbitrarios los 25 parámetros opcionales de las llamadas a herramientas, lo que hacía que entre 52% y 64% de las lecturas de archivos devolvieran resultados vacíos; al cambiar los campos opcionales a requeridos y nullable, las lecturas vacías bajaron a 0% y las llamadas a herramientas se redujeron cerca de 30%
  • Debido a diferencias en el alcance del caché y la estructura de throughput entre OpenAI y Anthropic, al principio GPT-5.6 parecía costar cerca de 50% más, pero al aplicar una cache key por workspace y breakpoints por capas, la tasa de acierto en la primera llamada subió de 0% a 83.7% y los tokens de entrada sin caché bajaron 28%
  • El costo y rendimiento de un cambio de modelo dependen no solo del modelo en sí, sino también del presupuesto de evaluación, el esquema de herramientas, la estructura del caché y la forma de reproducir el razonamiento, por lo que primero hay que detectar y corregir las suposiciones específicas del proveedor ajustadas al modelo anterior para lograr comparaciones confiables y una operación estable

GPT-5.6 Sol reemplaza a Claude Opus

  • El agente de Ploy planifica páginas de sitios web de marketing en producción, lee la base de código, genera componentes e imágenes, verifica el resultado con capturas de pantalla y decide si la tarea quedó completa
  • Durante varios meses no hubo un modelo que cumpliera el estándar para reemplazar a Claude Opus, y el modelo predeterminado se mantuvo durante 4 meses en el orden de Opus 4.7 y luego 4.8
  • GPT-5.6 Sol fue el primero en superar a Opus en una evaluación uno a uno sobre la misma tarea y pasó a ser el modelo predeterminado en todos los workspaces de Ploy
  • Incluso en la evaluación inicial, el tiempo de ejecución de los builds completados era menos de la mitad, el costo era 27% menor y la puntuación era igual o mejor que la del modelo anterior, dando base para avanzar con la migración
  • Ploy usa el Vercel AI SDK, pero durante el cambio de modelo descubrió que en todo el stack seguían presentes suposiciones específicas del proveedor sobre la composición de argumentos de herramientas, el prompt caching y la reproducción del razonamiento entre turnos
  • La migración avanzó corrigiendo, en este orden, el harness de evaluación, el esquema de herramientas, el prompt caching y la reproducción del razonamiento

Arreglar primero el harness antes de confiar en las métricas

  • La suite de evaluación ejecuta el agente de producción en workspaces de prueba fijos y cubre cientos de casos, desde tareas de construir una página principal desde cero hasta tareas para decidir si una solicitud de réplica puede ejecutarse de forma segura
  • En los casos de build, un evaluador visual realiza 10 verificaciones binarias comparando contra el diseño de referencia
    • Verifica si la sección hero es una escena fotográfica que ocupa todo el ancho de la pantalla
    • Confirma si el CTA principal es un rectángulo con esquinas redondeadas y no una pastilla
  • También se ejecutan verificaciones de contenido, rutas de ejecución de herramientas y aserciones sobre archivos, y cuando algo falla se revisa el rastreo completo de ejecución, incluidas las llamadas a herramientas y el texto del modelo

  • Restricciones ajustadas al patrón de llamada del modelo anterior

    • El presupuesto previo de llamadas a herramientas estaba ajustado al patrón secuencial de Opus, pero GPT-5.6 usa llamadas en paralelo y excedía ese presupuesto incluso en casos donde resolvía correctamente el problema
    • El ejecutor de evaluación no soportaba lectura de archivos por lotes, que Opus casi no usaba, pero GPT-5.6 sí usaba con frecuencia
    • Aproximadamente un tercio de los fallos brutos observados en la primera ejecución no venían del comportamiento del modelo sino de suposiciones del harness, y tampoco estaban distribuidos de forma uniforme entre modelos
    • Si primero no se clasifican los rastreos de ejecución del modelo retador y del modelo existente, la evaluación favorece al modelo nuevo cuanto más se comporte como el modelo viejo

  • Umbrales de puntuación implícitos

    • Los datasets sin minScore heredaban silenciosamente un valor predeterminado de 1.0
    • Por eso GPT-5.6 fue marcado como fallo pese a obtener 0.98 en el hero, y Opus también fue marcado como fallo en casos donde pasaba todas las verificaciones individuales
    • Ambos resultados eran diseños defendibles, pero quedaron fuera por un umbral implícito y no por el modelo

Resultados del benchmark corregido

  • Después de corregir el harness, volvieron a ejecutar la suite de evaluación para reconstruir una homepage de marca según el diseño de referencia
Promedio por build completado Claude Opus 4.8 (n=11) GPT-5.6 (n=10)
Costo $3.06 $2.22
Tiempo de ejecución 8 min 00 s 3 min 42 s
Tokens de entrada 2.6 millones 1.7 millones
Tokens de salida 33,000 17,100
Puntuación visual 0.936 0.970
  • GPT-5.6 completó las páginas 2.2 veces más rápido, costó 27% menos y además usó aproximadamente la mitad de tokens de salida
  • La cantidad de código generado también fue menor
    • En un par de casos comparados, Opus generó 174 variables CSS y un globals.css de 17,957 caracteres, incluyendo gamas de color que casi no se usaban
    • GPT-5.6 usó 45 variables CSS y 2,508 caracteres, pero produjo un resultado renderizado similar o mejor

  • Calidad y consistencia del diseño

    • GPT-5.6 es fuerte en layouts limpios y con cuadrículas densas, pero tiende a converger hacia ese estilo si no se le guía con fuerza
    • En el harness existente diseñado para Opus 4.8, con frecuencia generaba resultados limpios pero genéricos ignorando el sistema de diseño existente
    • Después de que los equipos de diseño e ingeniería mejoraron la forma de guiar al modelo, cumplió con los estándares de marca necesarios para producción

Manejo de parámetros opcionales en llamadas a herramientas

  • La herramienta code del agente tiene 25 parámetros de nivel superior; solo action es obligatorio y el resto son opcionales
  • Claude envía solo los 2 o 3 parámetros que usa, pero GPT-5.6 mandaba los 25 en cada llamada y llenaba incluso los campos no usados con valores plausibles como offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000"
  • El mismo patrón apareció en rastreos de ejecución de code(read) en producción recopilados durante 3 días
Modelo Número de llamadas Llamadas que incluían las 25 propiedades
gpt-5.6 6,635 6,635 casos, 100%
claude-opus-4.8 2,898 4 casos, 0.1%
claude-sonnet-5 1,933 0 casos

  • La causa de las lecturas vacías de archivos

    • El problema no era solo que los argumentos fueran verbosos, sino que la implementación de lectura de archivos no podía distinguir entre valores inventados por el modelo y valores realmente intencionados por el usuario
    • La implementación trataba offset: 0 como un argumento real, y entre 52% y 64% de las lecturas de archivos de GPT-5.6 devolvían resultados vacíos
    • La herramienta devolvía success: true tanto en lecturas válidas como en lecturas vacías, así que el modelo no podía saber que estaba leyendo archivos vacíos
    • Al hacer más llamadas para compensar esos resultados vacíos, también empeoraba la calidad del resultado

  • Un problema que no se resolvió con prompts ni con modo strict

    • Aunque se agregó a la descripción de la herramienta la instrucción de omitir parámetros no usados, los 25 seguían apareciendo
    • Incluso añadiendo OPTIONAL, omit if unused a cada propiedad, el comportamiento no cambió
    • En el modo strict de OpenAI ocurrió lo mismo, y para adoptarlo había que eliminar de todos los esquemas pattern, format y las validaciones de tamaño de arreglos
    • Como este comportamiento viene de cómo el modelo genera function calling, se cambió el esquema en lugar del prompt

  • Conversión del esquema en el límite entre proveedores

    • Para los modelos de la familia OpenAI, todas las propiedades opcionales se reescribieron como propiedades requeridas y nullable con la forma anyOf: [T, null]
    • El modelo llena los parámetros no usados con null explícito y luego esos null se eliminan antes de validar en el límite compartido de llamadas a herramientas
    • La implementación de la herramienta no cambió; solo se permitió en el esquema para el modelo representar valores no usados
    // Antes: las 25 claves se llenaban con valores arbitrarios
{ "action": "read", "file_paths": ["..."], "offset": 0, "timeout": 120000 }

// Después: envía 4 valores reales y 21 null; los null se eliminan antes de ejecutar la herramienta
{ "action": "read", "file_paths": ["..."], "offset": null, "timeout": null }
    • Después del cambio, las lecturas vacías de archivos bajaron de 52% a 0%
    • También se redujo cerca de 30% el número de llamadas a herramientas necesarias para la misma tarea, porque desapareció el patrón de releer resultados vacíos

Prompt caching ajustado a la forma de OpenAI

  • Ambos proveedores ofrecen prompt caching, pero su implementación es distinta
  • Antes de reflejar esa diferencia, GPT-5.6 parecía costar cerca de 50% más que Opus, pero la causa no era el precio del modelo sino la configuración del caché

  • Caché a nivel de organización en Anthropic

    • El prompt del agente comienza con un prefijo estático de unas 29,000 tokens compuesto por el esquema de herramientas y el prompt central del sistema, y es el mismo en todas las conversaciones
    • En Claude, cache_control marca breakpoints de caché y el prefijo se comparte a nivel de toda la organización
    • Cualquier conversación de cualquier workspace puede usar un elemento compartido y no hay límites de throughput por key
    • La tasa de acierto del caché es de 92% a 96%

  • Cómo cambió el comportamiento del caché en GPT-5.6

    • Los modelos GPT anteriores almacenaban implícitamente coincidencias parciales de prefijo, pero GPT-5.6 eliminó la coincidencia parcial de prefijo
    • Como el caché implícito crea un elemento de prompt completo según el mensaje más reciente, incluso una conversación nueva que comparte el mismo prefijo estático de 29,000 tokens tiene 0% de acierto en la primera llamada
    • Como resultado, en cada conversación se vuelve a cobrar todo el prefijo como entrada sin caché
    • Use o no la aplicación el caché, GPT-5.6 aplica un recargo de escritura en caché de 1.25x a todos los prompts sin caché

  • Restricciones de las cache keys explícitas

    • El caché explícito requiere prompt_cache_breakpoint y un prompt_cache_key obligatorio
    • La key también forma parte de la identidad del caché, así que aunque el prompt sea idéntico, si la key cambia no hay acierto
    • Cada key se asigna a un nodo de caché que procesa unas 15 solicitudes por minuto; si se supera ese nivel, OpenAI distribuye el tráfico a otros nodos con caché frío independiente
    • Por eso, decidir la unidad de la key es una decisión clave de diseño
    • Key por conversación: las conversaciones nuevas no acertaban el prefijo compartido y la tasa de acierto en la primera llamada era 0%
    • Una sola key global: todas las solicitudes se hashean a un nodo, y si el tráfico de producción supera 15 rpm se desborda a nodos fríos
    • Key por workspace: todas las conversaciones del workspace del cliente comparten el elemento y al mismo tiempo el tráfico por key se mantiene bajo

  • Caché jerárquico por workspace

    • La configuración real usa una key por workspace con formato ws:{workspaceId} y divide el prompt del sistema en capas de breakpoint
    • El elemento A contiene las herramientas y el prefijo estático, reduciendo el costo de la primera llamada de la sesión
    • El elemento B añade al prefijo estático el contexto del workspace
    • El elemento C es la cadena completa de prompt por sesión, desde el primer turno hasta el mensaje más reciente
    • Si cambia la memoria del workspace, el elemento B deja de acertar, pero el elemento A sigue acertando, así que solo se vuelve a escribir el tamaño del contexto modificado y no los 29,000 tokens completos
    • El elemento C aprovecha la cadena implícita completa de prompt de OpenAI dentro de la sesión porque el prompt sigue una estructura estrictamente append-only
    • Debido al particionamiento de keys de OpenAI, no es posible compartir el prefijo estático entre workspaces
    • En cambio, Anthropic usa un caché a nivel de organización sin particionamiento por keys, así que sí puede compartir ese prefijo
    • En GPT-5.6, cada workspace hace una sola escritura fría de 29,000 tokens por ventana de inactividad, con un costo aproximado de $0.18
    • Ese costo está acotado y es predecible

  • Resultado tras corregir el caché

    • La tasa de acierto en la primera llamada subió de cerca de 0% a 83.7%
    • El total de tokens de entrada sin caché se redujo 28%
    • El costo por suite de evaluación de GPT-5.6 quedó por debajo del de Opus, y toda la brecha inicial de costo provenía de una configuración incorrecta del caché
    • Una comparación de costos entre modelos donde solo uno empieza con caché frío no es válida

Reproducción del razonamiento convertida en autocontenida

  • La Responses API de GPT-5.6 reproduce por defecto el razonamiento del turno anterior mediante una referencia del servidor al elemento, y en conversaciones de producción aparecían errores intermitentes de Item 'rs_...' not found
  • Al establecer store: false, el SDK solicita encrypted reasoning content y reproduce un blob autocontenido en lugar de un puntero a estado del servidor
  • Aunque los bytes enviados por la aplicación sigan una estructura append-only, el estado de razonamiento del lado del servidor puede cambiar el prompt válido
  • Con el harness de evaluación, el esquema de herramientas, el prompt cache y la reproducción del razonamiento ya corregidos, GPT-5.6 Sol ahora opera como el modelo predeterminado de producción en Ploy

Lecturas relacionadas

1 comentarios

 
GN⁺ 1 일 전
Opiniones de Hacker News

  • Frases como “con esas cifras, realmente vale la pena migrar el modelo” suenan demasiado ridículas. Ojalá quien hizo escribir el texto hubiera pulido al menos el típico estilo de LLM
    La forma de encadenar frases cortas con dos puntos, comas y puntos también es pésima y frustrante. Hay buenas ideas, como que la caché por coincidencia de prefijo parcial desapareció en GPT-5.6, pero no es un texto cómodo de leer

    • Por eso siempre pongo un WRITING.md junto a AGENTS.md o CLAUDE.md. La mayoría solo le dice al modelo qué construir, y casi nunca cómo debe escribir, pero los LLM siguen sorprendentemente bien las instrucciones explícitas de estilo
      Escribí reglas para evitar dos puntos innecesarios, guiones largos, fragmentos de oración disfrazados de énfasis y errores gramaticales que suelo cometer; también puse como referencia a Brian Kernighan y Rob Pike, por su escritura técnica clara, conversacional y sin pretensiones. Un documento no solo debe ser fácil de leer, también debe dar ganas de leerlo
      Si generas documentos con frecuencia, vale mucho la pena hacer que el agente consulte WRITING.md. Muchas veces mejora la legibilidad mucho más que cambiar al modelo más reciente, y permite mantener un estilo consistente aunque cambies de modelo
    • Se ve todavía peor si se trata de una empresa de AI. Solo puede significar que no usan lo suficiente los modelos como para reconocer su estilo característico, o que no son conscientes de que eso importa, o que no entienden el panorama general, o que no respetan a sus lectores; ninguna opción es buena
    • Lo estás leyendo mal. Puedes pedirle a un LLM que lo lea y lo resuma según tus propias preferencias de estilo. Mejor aún: no leas nada directamente, haz que el agente lo convierta en un archivo de skills para consultarlo después
    • Si sospecho que un texto fue escrito con un LLM, dejo de leerlo de inmediato y hago que la herramienta LLM que uso lo resuma o lo reescriba. Así al menos puedo controlar en cierta medida el estilo de salida
    • En mi claude.md actual prohibí la expresión “load-bearing”, y Claude de verdad la odia. Le gusta tanto esa expresión que a veces incluso se burla en los comentarios con cosas como “load-be…most specific”

  • Migré a 5.6 varios workflows variados, pequeños y simples que antes corrían en 5.4-nano y mini, y en general mejoraron dentro del rango que menciona el artículo; incluso mejoró la calidad en algunas tareas de clasificación
    En muchas empresas, este tipo de actualización de modelo es básicamente cambiar una sola línea de código. Para workflows críticos usamos una excelente arquitectura de ruteo de modelos, pero no vale la pena armar eso para tareas simples, y también hay que considerar los problemas de estabilidad

    • El punto central del artículo es que la actualización del modelo no fue un cambio de una sola línea de código
    • ¿Qué SDK usan? ¿O es una implementación propia?
    • El objetivo inicial de usar Sol era evaluar 5.6 en nuestros workflows. Antes, los modelos simples no tenían suficiente calidad, así que usábamos 5.5 para todo; ahora analizamos texto e imágenes juntos para extraer datos estructurados explícitos e implícitos desde datos fuente desordenados
      En general funciona como se anuncia. Al enviar la mayor parte del trabajo actual a terra, el costo se redujo a la mitad y el tiempo de respuesta mejoró 50%. Usamos luna para complementar los resultados de detección de OpenCV; sus capacidades son muy limitadas, pero es rápido y casi gratis. En nuestro trabajo, Sol fue apenas un poco mejor que terra
      Sol ultra también hizo un gran trabajo con la evaluación en sí. Generó un material grande con recomendaciones razonables, una lista de salidas para revisar y comparar manualmente, datos originales y procesados, y el CPM por consulta. Sin gastar más que la suscripción Pro, tras correrlo unas horas, el costo de referencia bajó 50% y el throughput aumentó 100%

  • Mi experiencia es parecida. Los servicios como OpenRouter, que presumen de failover, casi no sirven más allá de pruebas en sandbox. En producción, los modelos no son realmente intercambiables entre sí, y los entornos de ejecución que realizan trabajo serio con agentes dependen de muchas más características específicas de cada modelo de lo esperado
    Aunque otro modelo funcione sin errores, el rendimiento y la eficiencia son otra cosa. Algunos modelos, como la familia Claude, requieren ajustar el prompt de sistema a las formas de expresión con las que se familiarizaron durante el entrenamiento; otros funcionan mejor con delimitadores distintos. Si importa el rendimiento óptimo, hay que ver el entorno de ejecución, el prompt y el modelo como un solo sistema, y no pensar que se pueden intercambiar libremente como piezas

    • Como parte de LLMOps, hay que construir un plan de failover que pruebe correctamente las rutas de ejecución de herramientas y demás. Así puedes colocar modelos suficientemente buenos del más barato al más caro e implementar el failover que quieres
      He visto casos donde hacen una tabla de correspondencia del tipo model -> {{prompts}, {tools descriptions}, ...}, pero eso es demasiado extremo. A partir de cierto punto, el modelo debe adaptarse a nuestros prompts; si no puede, se lo excluye de los candidatos de failover y no se envían solicitudes a su API
    • OpenRouter no hace failover a otro modelo, sino que cambia a otro proveedor que ofrece el mismo modelo

  • Es irónico que, debajo de un artículo lleno de ideas profundas sobre infraestructura, la mitad de los comentarios critiquen solo el estilo forzado. Aunque Claude haya ayudado a pulir las frases, si el texto contiene un plan aplicable de inmediato para reducir 30% el presupuesto de API y corregir lecturas de archivos vacíos, ¿no es eso más importante?

    • Habrá gente que odia cualquier cosa relacionada con la AI y busca cualquier detalle para criticar, pero también habrá quienes de verdad no soportan ese estilo y por eso se quedan fijados en eso
      Personalmente, quejarse del estilo me parece algo ridículo. Tal vez porque soy malo con la gramática y la ortografía, me concentro más en el contenido central: conceptos, hechos y argumentos, que en la forma de transmitirlo. La gramática y la ortografía son los árboles; el bosque es lo importante
      Si mis textos no tienen tantos errores es gracias al dictado y a atajos que hice yo mismo. Corrigen el texto seleccionado con un LLM local y luego lo reemplazan; nada ha mejorado tanto mi calidad de vida y la calidad de mi escritura como esas dos herramientas

  • “A partir de hoy, el agente de Ploy usa GPT-5.6 Sol, lanzado esta mañana”; entonces, ¿lo cambiaron con resultados de apenas medio día de pruebas? ¿La empresa la manejan adolescentes?

    • En realidad, la composición del equipo se parece más a niveles Staff y Senior Staff. A través de la relación con YC, probaron durante alrededor de una semana el modelo preliminar de GPT-5.6 y dieron feedback.
      Las evaluaciones se ejecutan en GitHub CI, y pueden correr en unos 15 minutos el conjunto completo de más de 115 evaluaciones sobre tareas de diseño web y marketing en las que se especializa ploy.ai. Después de activar el modelo con feature flags de PostHog, monitorearon activamente las fallas.
      Intentan trasladar a Ploy todo lo posible del conocimiento adquirido al operar Webflow, que soportaba más del 1% de internet, para poder soportar una porción aún mayor de internet.
    • Es muy posible que hayan recibido cierto acceso anticipado para evaluarlo lo suficiente como para poder escribir algo así.
    • Hoy ya es bastante fácil crear evaluaciones y benchmarks y ejecutarlos en los modelos más recientes. Como los LLM son fáciles de reemplazar, un buen conjunto de evaluación es muy útil y, a veces, la mejora es tan evidente que ni siquiera hace falta evaluar.
    • Supongo que tienen un dataset basado en producción para comparar modelos nuevos.

  • Aunque el agente de Ploy crea y modifica sitios web reales de marketing, planifica, lee codebases, escribe componentes, genera imágenes, captura sus propios resultados y decide si terminó, incluso sin pruebas rigurosas esperaría que Fable sea mucho mejor que Opus para crear sitios de marketing. En la creación de presentaciones, definitivamente es muy superior.

    • En diseño, GPT-5.6 es mucho mejor que Fable.
    • 4.7 tiende a seguir las instrucciones de forma demasiado literal, así que los resultados del texto original también suenan bastante plausibles.

  • La solución de cambiar solo en los modelos de la familia OpenAI todos los atributos opcionales para que sean obligatorios pero permitan null con anyOf: [T, null] huele a que algo está mal. Solo he usado una forma modificada de MCP, pero no está claro por qué las definiciones de tipos de TypeScript afectarían el JSON Schema que el agente envía al backend de inferencia.
    La especificación de MCP tiene un campo explícito para representar parámetros opcionales, así que parece haber un bug en algún punto entre la capa de TypeScript y la descripción de herramientas que realmente se transmite. Puede que el backend de inferencia haya pasado de “generar una respuesta de herramienta válida” a “generar una respuesta válida ajustada a un JSON Schema sin parámetros opcionales”, pero no se puede juzgar sin ver la solicitud real.

    • Esto no es un bug de generación de esquemas ni de TypeScript, sino el funcionamiento interno de las llamadas a funciones de OpenAI. Los pesos ajustados para el uso de herramientas intentan producir estructuras de datos lo más completas posible. Si el modelo ve nombres de parámetros en el contexto del prompt de sistema, intentará llenar valores aunque no estén en el arreglo required.
    • Los modelos frontier recientes, incluidos Fable, Opus y 5.6, son bastante laxos en las llamadas a herramientas y muchas veces no siguen el esquema con precisión. Un ejemplo de modelos Claude inventando propiedades inexistentes en llamadas a herramientas de edición y reemplazo de Pi puede verse en https://lucumr.pocoo.org/about/.
      Parte de la causa parece estar relacionada con que usar decodificación restringida reduce la inteligencia. Garantiza la validez del esquema, pero baja mucho la capacidad, así que puede estar bien para clasificación, resumen o mejora de prompts, pero hay que tener cuidado en ejecuciones iterativas de agentes.
      Entornos de ejecución como Claude Code hacen mucho preprocesamiento, recuperación y limpieza, pero normalmente eso no se ve. En la práctica, suele ser más fácil y mejor hacer el entorno de ejecución más flexible y adaptarlo a las particularidades de cada modelo, en lugar de asumir y exigir una precisión perfecta. Los modelos también cambian cada uno o dos meses. Esta es la IA aplicada hecha a puro vibe.

  • Me gustaría saber el monto aproximado de cuánto cuesta realmente crear un sitio con Opus y con Sol, respectivamente.

  • Al mover el workflow a Reasonix y aprovechar los cache hits en DeepSeek, el costo por solicitud se volvió prácticamente cercano a cero incluso usando proveedores estadounidenses no subsidiados.

    • ¿Qué configuración usas y cómo se compara con Pi?

  • En lugar de usar GPT-5.6 Sol por defecto en todos los workspaces de Ploy, valdría la pena considerar Luna para algunas tareas que manejan herramientas reales. Es sorprendentemente capaz y rápida.
    Sol es excelente para hablar con personas y coordinar llamadas de agentes, pero es demasiado caro para usarlo en todo. Por el precio de una ejecución de Sol se puede ejecutar Luna cinco veces, y estadísticamente la diferencia entre una muestra y cinco muestras es considerable.

    • Si cada paso de una ejecución de Luna tiene 90% de probabilidad de ser correcto, la probabilidad de que los cinco pasos sean correctos es 0.9^5 = 0.59, es decir, 59%. La precisión de una sola ejecución de Sol quizá ronde el 95%. Los números reales variarán, pero puede resultar más barato verificar al final con Sol.
    • Siempre aparece el problema de que los subagentes están aislados entre sí. Tiene la ventaja de mantener el contexto pequeño y enfocado, pero para continuar con la tarea asignada cada uno tiene que volver a investigar, lo que suele consumir tokens no cacheados.
      Según cuántos agentes se usen para qué tipo de tarea, puede terminar costando más y dando peores resultados.