Muse Wonder Full es solo por suscripción: qué significa para un equipo de agentes

El modelo más potente de Meta no está disponible en su API. Muse Wonder Full alcanza una puntuación de 56 en el Artificial Analysis Intelligence Index, empata con Claude Code en Sonnet 5.5 con 68 puntos en el Coding Agents Index y supera a todos los modelos en el benchmark histórico de generación de código de Meta. Solo es posible utilizarlo dentro de Muse Code, el agente para terminal de Meta, a través de los planes Power de 50 $ o Maximum de 200 $. Por su parte, la API solo ofrece la versión reducida, Muse Wonder, con puntuaciones de 52 y 63. No existe un precio por token para Full, ni gateway de acceso, ni una fecha prevista para su disponibilidad.

Para un desarrollador individual, esto es simplemente una decisión de precios. Para un equipo que coordina agentes desde un tablero compartido, se convierte en un dilema estructural: el mejor modelo de Meta queda aislado en la terminal de una sola persona, bajo su suscripción individual, sujeto a sus ajustes de privacidad de datos y fuera del alcance de cualquier Task asignada. En este artículo analizamos el impacto que esto genera en un Crew y cómo gestionarlo eficazmente.

Los dos modelos Wonder desde la perspectiva de un equipo

La columna de la derecha representa una herramienta personal. La de la izquierda, un carril de trabajo compartido. Todo lo que analizamos a continuación surge de esa diferencia fundamental.

Lo que pierde un equipo cuando el mejor modelo es de uso individual

El trabajo desaparece del tablero. El verdadero valor de Sharkly reside en que la asignación, el progreso, los bloqueos, los resultados y las revisiones son visibles desde la petición inicial hasta el despliegue. Una sesión en Muse Code carece de todo esto. Si el modelo más capaz solo se ejecuta de forma local, las Tasks más complejas terminan recayendo informalmente en quien disponga de la suscripción, dejando en el tablero una tarea marcada como completada sin trazabilidad de ejecuciones, sin registros y sin un historial auditable.

La configuración de una persona se convierte en la política del equipo. Las suscripciones de Muse Code activan por defecto el modo Contributor, que permite a Meta entrenar sus modelos con los prompts, el código y las respuestas generadas a cambio de mayores límites de uso. Aunque el suscriptor puede desactivarlo, nadie más en el equipo tiene forma de verificar si lo ha hecho. En cambio, un Runtime alojado en un Computer se comunica con la API en modo Standard —donde el tráfico jamás se emplea para entrenamiento— garantizando esta política en todos los Agents del equipo sin depender de intervenciones manuales.

La capacidad depende de un plan individual, no de una clave compartida. Los planes de Muse Code restablecen sus cuotas en ventanas de cinco horas y semanales. La semana de lanzamiento dejó en evidencia los problemas de este esquema: Wonder y Full agotaron las cuotas a un ritmo anómalo desde el primer día, obligando a Meta a reiniciar los límites de todos los usuarios, mientras Alexandr Wang reconocía públicamente que aún quedaban incidencias por resolver. En cambio, un carril en la API cuenta con restricciones distintas —3.000 peticiones y 4 millones de tokens por minuto compartidos entre todo el equipo—, permitiendo una gobernanza centralizada desde el tablero que resulta imposible a nivel individual.

El rendimiento real no coincide con los benchmarks de referencia. La comunicación oficial de Meta destaca las métricas obtenidas por Full. Quien planifique la capacidad de su equipo basándose en esas cifras estará dimensionando para un modelo que su Crew no puede ejecutar. La referencia aplicable para un equipo es la de Wonder: 52 puntos en el índice general, 53.1 en SWE-Marathon y 25 en razonamiento y conocimiento. Sigue siendo un ejecutor sólido para procesos de larga duración; además, su configuración se resuelve en apenas una tarde.

Qué margen de maniobra conserva el equipo

Nada de esto convierte a Full en una herramienta inútil. Sencillamente redefine su encaje operativo, encontrando su lugar natural donde herramientas como Claude Code o Codex en terminal local ya aportan valor: en la fase de exploración del lead engineer, en los spikes técnicos que aún no han sido acotados o en sesiones de depuración complejas que todavía no pueden formalizarse en una Task. Full supera al resto en cuatro puntos justamente en ese tipo de tareas; úsalo ahí.

La clave radica en establecer una disciplina estricta de relevo. En cuanto una sesión en Muse Code transforma una incógnita en un plan de acción concreto, ese plan debe plasmarse en una Task visible para todo el equipo en el tablero. A partir de ahí, el Wonder Agent del Crew —o su equivalente Opus 5.5— se encarga de la ejecución delimitada, generando un registro de ejecución completo y facilitando la revisión. La exploración permanece en manos del suscriptor; el control y el registro histórico, en manos del equipo.

Dos buenas prácticas permiten consolidar este flujo de trabajo:

• Indicar explícitamente el modelo en la Task. Como Sharkly no muestra nombres de modelos por defecto, las instrucciones del Agent deben incluir el identificador del modelo en la cabecera de su informe. Del mismo modo, cualquier desarrollador que traslade resultados desde Muse Code debe declararlo en los comentarios de la Task. Un revisor que desconozca si un diff proviene de Full en local o de Wonder a través de la API no podrá calibrar adecuadamente el alcance de los cambios.
• Definir el modo Contributor a nivel de equipo. Si algún miembro cuenta con una suscripción a Muse Code e interactúa con los repositorios compartidos, la desactivación del envío de datos debe ser una directriz consensuada y documentada, nunca una preferencia personal librada al azar. En nuestro artículo sobre inyección de prompts y barreras de seguridad para agentes explicamos en detalle por qué el verdadero punto de control reside en la fase de revisión y no en el modelo en sí.

Un caso práctico: una semana de trabajo

Imaginemos un equipo de cinco ingenieros durante la primera semana tras el lanzamiento. El lead suscribe el plan Muse Code Power el primer día y dedica toda la jornada del lunes a explorar con Full una migración técnica compleja que nadie quería asumir. Para el martes ya cuenta con una estrategia clara: cuatro módulos independientes, cada uno respaldado por tests para asegurar su estabilidad. Esos cuatro bloques pasan a ser Tasks en el tablero, asignadas al Wonder Agent sobre el Runtime de Codex, ejecutándose en paralelo en el Computer del equipo mientras el lead supervisa los avances desde la bandeja de entrada. Dos de ellos se completan sin fricción. El tercero plantea una consulta sobre un cambio de esquema fuera de los repositorios vinculados, que el lead responde directamente mediante un comentario en la Task. El último falla su batería de pruebas dos veces consecutivas, reintenta la implementación y se resuelve con éxito al tercer intento, dejando un registro detallado de las tres iteraciones.

En ningún momento de esa semana fue necesario que Full estuviera integrado en el tablero. Full resolvió la fase previa a la definición de las Tasks; Wonder se encargó de materializarlas. La trazabilidad refleja con exactitud qué se hizo y con qué modelo, gracias a que las instrucciones del Agent fijan el identificador al inicio de cada informe y el comentario del lead documenta que la planificación inicial surgió de una sesión en Muse Code. Esta es precisamente la división del trabajo sobre la que se fundamenta Sharkly: las herramientas de ejecución llevan a cabo las tareas técnicas, mientras el tablero centraliza y hace visible la asignación, el contexto, los bloqueos, los resultados y las revisiones.

El escenario opuesto resulta igualmente predecible: el lead implementa los cuatro módulos directamente en Full aprovechando su disponibilidad inmediata, sube la rama el jueves y obliga al equipo a revisar un diff de 2.000 líneas sin trazas de ejecución ni pistas sobre qué decisiones generaron dudas al modelo. Se gana velocidad el lunes a costa de paralizar la entrega el viernes.

¿Llegará la versión Full a la API?

El blog oficial para desarrolladores de Meta señala que Full solo se encuentra disponible mediante suscripciones a Muse Code y no fija plazos para su apertura. La lógica comercial es evidente: Full constituye el principal incentivo para pagar 50 $ al mes, y un modelo de tarificación por token entraría en conflicto directo con ese negocio. Al mismo tiempo, Meta ha publicado tres variantes de API, ha documentado el uso de Claude Code y Codex con Wonder y ha desplegado este último en Vercel y Cloudflare desde la primera semana, demostrando que su API no es un aspecto secundario. Lo más previsible es que Full se incorpore a la API cuando un nuevo modelo tome el relevo en la cúspide de Muse Code. La estrategia recomendada es planificar los flujos de trabajo sobre Wonder y reevaluar la situación cuando se actualice el catálogo oficial de modelos.

Resumen de decisión

Disponer de un modelo con cuatro puntos más de rendimiento frente a los que pueden ejecutar tus Agents es un argumento válido para mantener una suscripción, no para sacar el trabajo del tablero. Las ejecuciones que verdaderamente aportan valor son aquellas que todo el equipo puede auditar.