TokenLab Fusion: Evidencia del DRACO Weighted-100 Research Dataset

Nota sobre el estado de la investigación: TokenLab Fusion: este es un resultado de investigación de "prueba de receta" y una línea base histórica sólida, no una afirmación de producción. Los resultados se obtuvieron utilizando un ancla premium de Gemini; una ejecución de prueba (canary) sin componentes premium y una re-ejecución final solo con Fusion están pendientes para confirmar la reproducibilidad sin dependencias premium. DRACO weighted-100 es una evaluación interna propietaria de TokenLab y no es un benchmark externo o estandarizado. Interprete los resultados en consecuencia.

Resumen

Este informe documenta el estado probatorio actual de TokenLab Fusion, un sistema de orquestación de inferencia multi-modelo evaluado frente a un conjunto de investigación fijo de 100 tareas ponderadas y multidominio (el manifiesto de investigación DRACO weighted-100, que cubre Finanzas, Compras/Comparación de productos, Académico, Tecnología, Conocimiento general, Diseño UX, Derecho, Medicina, tareas de "aguja en un pajar" y Asistente personalizado). La pregunta central de la investigación no es si un conjunto de modelos puede obtener una puntuación agregada más alta que un solo modelo en una muestra de benchmark, sino si una receta disciplinada (composición del panel, síntesis, validación basada en rúbricas, obtención de evidencia y contabilidad de costos) puede organizarse en un sistema reproducible, auditable y actualizable que supere a las líneas base de modelos individuales sólidos en todos los dominios, no solo en un subconjunto favorable.

La evidencia más sólida hasta la fecha proviene de la ejecución de investigación weighted-100, una evaluación emparejada y habilitada para líneas base frente a gpt-5.5 y claude-opus-4-8 en el conjunto de datos fijo de 100 tareas DRACO. TokenLab Fusion obtuvo una media de 86.04, con una delta media emparejada de +32.60 sobre gpt-5.5 (ganadas/perdidas/empates 95/4/1, costo 0.71x, puntuación por dólar 2.26x) y +45.63 sobre claude-opus-4-8 (ganadas/perdidas/empates 97/2/1, costo 0.69x, puntuación por dólar 3.06x). Estas cifras son sólidas, emparejadas y reproducibles frente a un manifiesto fijo, pero conllevan dos calificaciones importantes que este informe trata como hallazgos de primer nivel, no como notas al pie: la receta ganadora utilizó un modelo histórico premium de Gemini Pro (gemini-3.1-pro-preview) como ancla de síntesis/juez/validador, y el estado de preparación para el lanzamiento del sistema aún requiere una re-ejecución final solo con Fusion antes de que el resultado pueda considerarse completo. El resto de este informe separa lo que se ha probado en la ejecución de investigación de línea base sólida de lo que permanece restringido antes de cualquier afirmación de producción, y expone la evidencia específica que aún se necesita, más urgentemente una prueba canary sin Gemini premium, para cerrar esa brecha.

1. Alcance y objetivo de la investigación

TokenLab Fusion se define aquí como una orquestación en tiempo de inferencia a través de múltiples modelos ascendentes, no como un modelo de pesos fusionados entrenado. Una sola solicitud se enruta a través de varios roles de modelo (panelista, sintetizador, validador, juez, revisor, propietario de herramientas), y la receta controla cómo se generan, comparan, reescriben y devuelven los resultados. Esto se acerca más a una configuración de producción multi-modelo verificable que a una votación de conjunto sin estado; comparte ascendencia estructural con Mixture-of-Agents y LLM-Blender, aunque el aparato de selección de recetas y contabilidad de costos descrito a continuación va más allá de ambos.

El objetivo de la evaluación es el conjunto de investigación weighted-100: un conjunto fijo de tareas de investigación multidominio, densas en evidencia y estrictamente puntuadas mediante rúbricas. El programa de investigación rechaza explícitamente las comparaciones de líneas base débiles. Las únicas líneas base aceptadas son gpt-5.5 y claude-opus-4-8, y ambas se mantienen estrictamente fuera de los roles de panel, síntesis, juez, validador y propietario de herramientas de Fusion; contaminar el panel con el modelo de línea base invalidaría cualquier afirmación de que "una receta multi-modelo más barata supera a un modelo individual sólido".

Los identificadores de modelo referenciados en este documento--gpt-5.5, claude-opus-4-8, gemini-3.1-pro-preview, deepseek-v4-pro y glm-5.2--son IDs de modelo lógicos de la plataforma TokenLab Fusion e IDs de línea base de investigación capturados de la instantánea de fuente única de verdad (SSOT) de modelos de TokenLab observada el 2026-07-07. Estos identificadores denotan etiquetas de enrutamiento y evaluación internas en lugar de una tabla de clasificación independiente auditada públicamente, y no se afirma que estos nombres correspondan uno a uno con la denominación de lanzamiento público de ningún proveedor externo. Identificadores como gpt-5.5 y claude-opus-4-8 son etiquetas internas de línea base y enrutamiento extraídas de la SSOT de TokenLab y no deben interpretarse como designaciones de versión de modelo de proveedor público. En consecuencia, las comparaciones de línea base sólida en este documento no deben leerse como una afirmación completa de preparación para la producción: la evaluación canary sin Gemini premium y la re-ejecución final solo con Fusion aún no se han completado y permanecen restringidas a la espera de una validación adicional. Los resultados presentados aquí representan una comparación de investigación en un momento dado, no un resultado de benchmark de producción finalizado o totalmente validado.

Dos líneas de productos comparten esta infraestructura de investigación pero divergen en la receta: una línea de Investigación Profunda (basada en evidencia, verificada en suficiencia de fuentes, con validadores pesados) y una línea de Agente de Codificación (pesada en ejecución de herramientas, sensible a la latencia, aún en pre-Fase-0). Este informe trata principalmente sobre la línea de Investigación Profunda, ya que es donde existe actualmente evidencia emparejada frente a líneas base sólidas.

2. Por qué un manifiesto fijo de 100 tareas

Una ejecución de benchmark de una sola muestra no puede respaldar decisiones de receta. El manifiesto de 100 tareas existe para cumplir seis funciones de ingeniería distintas simultáneamente: selección de recetas entre dominios (evitando el sobreajuste a una muestra afortunada), datos de entrenamiento de políticas de enrutador, evidencia de asignación de roles de modelo, construcción de curvas de costo/calidad/latencia, una biblioteca de fallos para pruebas de regresión y futuras pruebas canary de actualización de modelos, y un conjunto de regresión en capas reutilizable que no necesita una re-ejecución completa cada vez que cambia un modelo ascendente.

El manifiesto utilizado en los experimentos reportados es weighted-100-v1, una muestra ponderada determinista con un hash de conjunto de tareas fijo (b08a09aacbc76c5e5aafd5ca0a6fa614a5061bc478f905007ae5aee4a93fc43a). Su ponderación por dominio no es uniforme: Finanzas (20), Compras/Comparación de productos (16), Académico (12), Tecnología (10), Conocimiento general (9), Diseño UX (9), Derecho (6), Medicina (6), Aguja en un pajar (6), Asistente personalizado (6). Esta distribución importa porque las ganancias de Fusion dependen del dominio, y Finanzas en particular conlleva el riesgo abierto más persistente (Sección 6).

DRACO weighted-100 es un conjunto de datos de investigación interno de TokenLab utilizado exclusivamente dentro del pipeline de evaluación de TokenLab Fusion de este documento. No es un benchmark externo mantenido públicamente, y no está afiliado, respaldado ni extraído de ningún conjunto de benchmarks de terceros. El manifiesto weighted-100, incluyendo su muestreo de elementos, esquema de ponderación de categorías y metadatos de procedencia, se rige por un mapa de fuentes privado de TokenLab que no se publica junto con este documento. Por lo tanto, las puntuaciones reportadas deben interpretarse como señales comparativas internas específicas de la metodología de evaluación de TokenLab en lugar de puntuaciones comparables a tablas de clasificación públicas o benchmarks comunitarios. Los lectores no deben asumir que los resultados de DRACO weighted-100 se generalizan o pueden compararse con cualquier otro conjunto de datos que tenga un nombre o estructura similar.

3. Metodología

El ciclo de investigación es primero la evidencia: cada afirmación sólida debe ser rastreable hasta un manifiesto fijo, IDs de tarea, ponderaciones de dominio, configuraciones de tiempo de ejecución, archivos de resultados sin procesar, filas de costos y filas de línea base. Los números de resumen agregados sin esos artefactos no se tratan como evidencia.

Cuatro compromisos metodológicos son los más importantes.

Evidencia compartida sobre búsqueda nativa opaca

Las herramientas de búsqueda, obtención y lectura producen un paquete de evidencia externo a los modelos bajo prueba, y ese mismo paquete se proporciona tanto al panel como a los modelos de línea base siempre que sea posible. Esto aísla el "¿puede el modelo razonar y sintetizar bien?" de "¿el modelo buscó bien por casualidad?", y es un requisito estricto para las ejecuciones de prueba del conjunto de investigación weighted-100, comparaciones de líneas base sólidas, pruebas canary de actualización de modelos y re-ejecuciones finales.

Contabilidad de costos separada por roles

En una ejecución habilitada para línea base, la columna de costo agregado mezcla llamadas de Fusion y llamadas de línea base; usarla directamente exageraría o subestimaría la afirmación de costo solo de Fusion. El análisis de la ejecución de investigación weighted-100 excluye explícitamente las filas de línea base y de puntuación de línea base para llegar a un total oficial solo de Fusion de $12.837461 en 799 filas de costos. Esta distinción, filas de costos separadas por roles en lugar de totales combinados, es la base para cada afirmación de calidad ajustada por costo en este informe.

Comparación emparejada sobre medias no emparejadas

Las salidas de Fusion y de la línea base se comparan con IDs de tarea idénticos, y los resultados se reportan como delta media, intervalo de confianza bootstrap, valor p de prueba de signos, recuento de ganadas/perdidas/empates, multiplicador de costo, multiplicador de latencia y delta de tasa de fallos. Las medias no emparejadas con diferente cobertura de tareas no se aceptan como prueba.

Ejecución reanudable y fragmentada

La ejecución de investigación weighted-100 se ejecutó como diez fragmentos de diez tareas cada uno, luego se agregaron en un único artefacto de prueba. La re-ejecución final solo con Fusion (Sección 6) utiliza el mismo patrón escalonado y reanudable.

Dimensión de métodos	Enfoque utilizado	Justificación
Selección de tareas	Manifiesto fijo ponderado de 100 tareas, con hash	Evita muestras seleccionadas a dedo, permite re-ejecuciones
Obtención de evidencia	Paquete de evidencia compartido y reproducible	Aísla la calidad del razonamiento de la suerte en la búsqueda
Aislamiento de línea base	gpt-5.5, claude-opus-4-8 excluidos del panel/synth/juez/validador	Evita la contaminación de la línea base en la afirmación de Fusion
Contabilidad de costos	Filas separadas por roles; los totales solo de Fusion excluyen llamadas de línea base	Evita la distorsión de costo/dólar de costos combinados
Diseño de comparación	Emparejado, mismos IDs de tarea, IC bootstrap, prueba de signos	Controla la varianza de dominio y muestra
Ejecución	Ejecutores fragmentados y reanudables	Permite el seguimiento del progreso parcial y re-ejecuciones escalonadas
Puntuación	Puntuación de validador/juez basada en rúbricas frente a rúbricas de dominio	Permite la ablación del validador y la descomposición de la puntuación

TokenLab Fusion evalúa las salidas de los modelos a través de un pipeline de puntuación automatizado que agrega múltiples señales de métricas en una puntuación compuesta. Las reglas de puntuación se aplican programáticamente sin revisión manual en esta etapa. Los datos de auditoría humana pública o acuerdo entre evaluadores para este método aún no se han publicado; los resultados reportados reflejan solo la evaluación automatizada, a la espera de verificación independiente.

Disponibilidad de datos

El hash del manifiesto, las filas de costos, los archivos de resultados sin procesar, la instantánea de fuente única de verdad de modelos y el mapa de fuentes que subyacen a este estudio se conservan en el archivo de investigación interno de TokenLab. Estos materiales tienen acceso restringido y no se publican junto con este documento. En consecuencia, la reproducibilidad pública es limitada hasta que se publique una muestra redactada o un subconjunto público de los datos subyacentes.

4. Evolución de la receta: Más modelos no es la palanca

Un hallazgo temprano e importante es negativo: agregar más modelos al panel no mejora la calidad de manera confiable, y no se puede asumir que lo haga. La receta evolucionó a través de una secuencia de ablaciones controladas en lugar de escalar el tamaño del panel.

Núcleo rápido como grupo de control

Un panel de tres modelos de bajo costo, diverso y estable (gemini-3.1-flash-lite, deepseek-v4-flash, grok-4-1-fast-non-reasoning) sirve como condición de control de costo/latencia contra la cual se mide cada adición y cada variante de validador.

Combinación concreta de modelos de bajo costo

TokenLab Fusion es una capa de orquestación en tiempo de inferencia, no un modelo de pesos combinados: coordina llamadas a varios modelos existentes y combina sus resultados durante la ejecución. Para concretar esto, los modelos de referencia gpt-5.5 y claude-opus-4-8 se excluyen de cada rol de Fusion —panel, síntesis, juez, validador, revisor y propietario de herramientas— de modo que las ganancias reportadas no puedan atribuirse a que dichas referencias realicen trabajo oculto dentro del flujo.

La configuración predeterminada es un panel de control rápido y de bajo costo compuesto por tres modelos ejecutados en paralelo, con un cuarto panelista opcional evaluado en modo de calidad, un ancla histórica de prueba de techo y un candidato "canario" sin prima que aún espera evidencia emparejada.

Rol	Modelo(s)	Estado
Panel de control rápido de bajo costo	gemini-3.1-flash-lite, deepseek-v4-flash, grok-4-1-fast-non-reasoning	Panel predeterminado de bajo costo en evaluación
Candidato de adición de calidad	kimi-k2.7-code	Evaluado como cuarto panelista; no promovido — añade latencia, presenta regresión en algunos dominios con el validador
Ancla de prueba histórica	gemini-3.1-pro-preview	Utilizado para síntesis/juez/validador/revisión en la receta de referencia fuerte; prueba un techo, no la ruta de costo de producto prevista
Candidato "canario" sin prima	deepseek-v4-pro (síntesis/validación/revisión), glm-5.2 (juez independiente)	Ruta de costo prevista; pendiente de evidencia "canaria" emparejada

La orquestación procede como una secuencia fija en lugar de un conjunto desordenado de llamadas a modelos:

1. Construir un paquete de evidencia compartido una sola vez, para que cada panelista razone sobre un contexto idéntico.
2. Ejecutar los panelistas de bajo costo en paralelo contra ese paquete de evidencia.
3. Normalizar las salidas del panel en un formato común para su comparación.
4. Ejecutar el análisis del panel para identificar acuerdos, conflictos y evidencia faltante.
5. Sintetizar una respuesta única, luego ejecutar un validador basado en rúbricas y revisar una vez si el validador señala problemas.
6. Puntuar/juzgar la respuesta final, con un único propietario de herramienta designado; los panelistas nunca ejecutan herramientas directamente.

El resultado de kimi-k2.7-code y el candidato "canario" deepseek-v4-pro/glm-5.2 pendiente se reportan por separado de las cifras del panel predeterminado para evitar confundir una configuración evaluada pero evaluada pero no adoptada con la receta de costo de producto prevista.

Adición de Kimi: una señal real pero marginal

Un piloto de 20 tareas que agregó un modelo de codificación/diversidad al núcleo rápido produjo una puntuación media de 34.36 frente a 31.37 del núcleo rápido (delta emparejada +2.99, IC 95% -0.04 a 6.10, ganadas/perdidas/empates 11/6/3, costo ~1.01x, latencia ~1.57x). El IC que abarca el cero y un valor p de prueba de signos de 0.3323 significan que esto no es lo suficientemente fuerte como para justificar hacer de la adición un valor predeterminado sensible a la latencia; también regresó en algunas tareas de Académico, Medicina y Tecnología. La conclusión extraída es específica del rol: esta clase de modelo se trata mejor como un especialista en codificación/front-end/contexto largo que como un panelista de propósito general siempre activo.

Las adiciones de GLM y DeepSeek Pro necesitan roles, no inclusión general

Una adición de GLM produjo solo alrededor de +1.22 a 1.49x de costo y 1.85x de latencia en una pequeña muestra, evidencia útil para un rol de juez/synth/revisor de codificación, no evidencia suficiente para la promoción predeterminada del panel. La evaluación de DeepSeek V4 Pro cambió materialmente después de una corrección de precios (entrada $0.435, salida $0.87 por 1M de tokens), lo que invalidó un juicio anterior de "demasiado caro" y lo elevó a candidato principal para un rol de synth/validador en una receta de menor costo (Sección 6). La corrección de precios de DeepSeek V4 Pro deriva de la SSOT de modelos interna observada el 2026-07-07 y constituye una suposición de costo de investigación en lugar de una cita de un precio publicado por el proveedor externo.

Validador/reescritura es la palanca única más grande encontrada

En una expansión de 20 tareas, agregar una etapa de validador/reescritura consciente de rúbricas al núcleo rápido produjo una puntuación media de 81.70 frente a 29.88 para el núcleo rápido solo, una delta emparejada de +51.81 (IC 95% 42.64 a 61.23), ganadas/perdidas/empates 20/0/0, a 2.14x de costo y 1.89x de latencia. Esto no es una mejora incremental; es un cambio estructural en lo que la receta es capaz de hacer. Tampoco es gratis: el multiplicador de costo excedió el umbral de mantenimiento automático de 2.0x en una pasada de análisis, lo que significa que el mismo resultado que vale inequívocamente la pena para un nivel de investigación profunda es una restricción real para un nivel de producto rápido/barato. Se probaron alternativas más baratas y se rechazaron como valores predeterminados: una variante de revisión ligera/stack ligero perdió aproximadamente 28 puntos en relación con la validación completa y perdió cada comparación emparejada; la validación selectiva basada en heurísticas de dominio débil ahorró solo alrededor del 11% del costo mientras perdía -8.53 en puntuación media, y una variante selectiva de alto riesgo perdió más. Por lo tanto, la validación selectiva sigue siendo un problema de investigación de enrutamiento abierto, no una técnica de reducción de costos resuelta.

5. Resultados de línea base sólida: Lo que se probó

La ejecución de investigación de línea base sólida weighted-100 es el artefacto de evidencia más fuerte del programa. Mantiene a gpt-5.5 y claude-opus-4-8 como comparadores solo de línea base, excluidos de cada rol de Fusion.

Resumen solo de Fusion en las 100 tareas:

Métrica	Valor
Puntuación media	86.04
Costo total oficial	$12.837461
Costo medio oficial	$0.128375
Costo total de la plataforma	$6.568959
Puntuación por dólar oficial	670.21
Llamadas fallidas	0
Tasa de fallos	0.0%
Latencia media de llamada	216.4s
Filas de costos	799
Tareas de respaldo agregadas	0

El valor reportado de 670.21 denota la puntuación media bruta solo de Fusion dividida por el costo medio oficial solo de Fusion, mientras que las cifras de 2.26x y 3.06x representan multiplicadores de puntuación por dólar relativos a la línea base emparejada calculados frente a configuraciones de comparación coincidentes.

Comparación emparejada frente a las dos líneas base sólidas:

Línea base	Puntuación media línea base	Delta Fusion	IC 95%	Ganadas/Perdidas/Empates	Múltiplo costo Fusion	Ratio Puntuación/$	Múltiplo latencia
gpt-5.5	53.43	+32.60	28.13 – 37.28	95/4/1	0.71x	2.26x	1.23x
claude-opus-4-8	40.41	+45.63	40.85 – 50.21	97/2/1	0.69x	3.06x	2.15x

La calidad y la calidad ajustada por costo son victorias inequívocas de Fusion en este manifiesto. La delta de tasa de fallos de 0.0 puntos porcentuales hace que la estabilidad sea un empate en lugar de un diferenciador. La latencia es una clara pérdida de Fusion: 1.23x más lenta que gpt-5.5 y 2.15x más lenta que claude-opus-4-8. El encuadre honesto del producto a partir de estos datos es investigación profunda de alta calidad, eficiente en costos y verificable, no chat interactivo de baja latencia.

El desglose por dominio muestra deltas positivas en todos los dominios frente a ambas líneas base, lo que argumenta en contra de que la mejora sea un artefacto de un solo dominio. Valores seleccionados: frente a gpt-5.5, Finanzas +37.13, Compras +38.20, Aguja en un pajar +62.56, Tecnología +33.49; frente a claude-opus-4-8, Compras +55.96, Aguja en un pajar +69.38, Tecnología +52.43, Diseño UX +52.77. Finanzas es también el dominio que conlleva el riesgo no resuelto más claro: ocho advertencias de evidencia de alta severidad, todas en Finanzas, marcadas como finance:needs_more_sources, citando brechas en términos de métricas, términos de período y obtención de fuentes del período primario actual. Estas no son fallas de llamada; son advertencias de suficiencia de fuentes, lo que indica que el enrutamiento de evidencia específico de Finanzas aún no está totalmente resuelto incluso donde la delta de puntuación es grande.

6. Estado de preparación: Probado vs. Restringido

Es importante separar dos capas de estado. Este es un resultado de prueba de receta, no un resultado de sistema enviado, y el seguimiento de preparación utilizado en todo el programa refleja esa distinción explícitamente.

Aprobado: manifiesto fijo ponderado de 100 tareas, política de panel, prueba de enrutador de evidencia, prueba de ablación de panel, prueba de ablación de validador/synth, la configuración de línea base sólida en sí misma, la prueba de puerta de fuente débil, artefactos de receta y la prueba emparejada de línea base sólida descrita en la Sección 5.

Aún no aprobado: la re-ejecución final solo con Fusion.

La re-ejecución final no es una segunda comparación frente a las líneas base sólidas; su propósito es diferente y más estrecho: confirmar que la receta ganadora congelada se reproduce en el mismo manifiesto de 100 tareas sin costo de línea base en la ejecución, que la configuración de tiempo de ejecución coincide con la definición de la receta, que las filas de costos están completas y que no hay contaminación de línea base en la ruta solo de Fusion. A partir de la última ejecución escalonada, la cobertura se sitúa en 20 de 100 tareas puntuadas, 20 de 20 compatibles con el tiempo de ejecución, costo oficial solo de Fusion de $2.619654, costo de línea base $0, con las 80 tareas restantes por ejecutar en etapas de compensación adicionales.

Esta distinción importa para cómo deben leerse los números de la ejecución de investigación weighted-100: la delta de línea base sólida es real y emparejada, pero se midió con una receta que aún no se ha reproducido independientemente de principio a fin sin costo de línea base en el bucle, y utilizó un ancla de síntesis/validador/juez que la ruta de costo de producto está tratando deliberadamente de retirar.

Sobre el ancla de Gemini Pro específicamente, la receta congelada que produjo estas cifras utilizó gemini-3.1-pro-preview, un modelo histórico premium de Gemini Pro, como ancla de síntesis/juez/validador. Esa configuración establece el techo de lo que pueden lograr la estructura de la receta y la validación consciente de rúbricas, pero no es la configuración que la ruta de costo de producto pretende enviar. Debido a que el precio premium de Gemini Pro no se ajusta al perfil de costo objetivo, el siguiente artefacto de evidencia requerido es una prueba canary sin Gemini premium: una re-ejecución emparejada a menor escala que sustituya deepseek-v4-pro para síntesis/validación y glm-5.2 para juzgar, ejecutada frente a los mismos IDs de tarea antes de que se haga cualquier afirmación de que la receta eficiente en costos coincide con el techo de calidad probado.

7. Protocolo y compatibilidad: Por qué un endpoint de chat no es suficiente

Una receta que solo funciona contra un único endpoint de chat compatible con OpenAI no sobrevivirá al contacto con clientes de agentes de codificación reales. Chat Completions es suficiente para el uso conversacional simple, pero elimina la semántica de la que dependen los clientes de agentes: elementos de salida tipados, emparejamiento de llamadas a funciones/resultados de herramientas, eventos de elementos en streaming, historial con estado frente a sin estado y garantías de ordenamiento específicas del proveedor.

Las superficies que importan, y la semántica que conlleva cada una, difieren lo suficiente como para que no puedan colapsarse en una sola forma sin pérdida:

Superficie	Semántica clave que debe preservarse
Respuestas OpenAI	elementos de salida tipados, jerarquía de instrucciones de desarrollador/sistema, llamadas a funciones y salidas de llamadas a funciones, previous_response_id, store, eventos de elementos en streaming, contabilidad de uso
Chat OpenAI	mensajes/herramientas heredados; utilizable como fachada degradada, pero las pérdidas de compatibilidad deben registrarse
Mensajes Anthropic	campo de sistema de nivel superior, bloques de contenido, tool_use/tool_result, solicitudes de historial completo sin estado, stop_reason, errores de stream post-200
Perfil de cliente estilo Codex	Primero respuestas, store, previous_response_id, argumentos de herramientas en streaming, reproducción de resultados de herramientas, ordenamiento estricto de eventos
Perfil de cliente estilo Claude Code	Mensajes Anthropic, ordenamiento inmediato de tool_result, lotes de herramientas paralelos, disable_parallel_tool_use, listas de permitidos de descubrimiento de modelos

La respuesta arquitectónica es una representación intermedia canónica (IR). Los protocolos externos se asignan a una representación interna de solicitud/respuesta/stream/herramienta/uso/error/traza, y la ejecución de la receta y los adaptadores de proveedor operan contra esa IR en lugar de contra cualquier protocolo de cable único. La IR debe llevar, como mínimo: identificadores de conversación y turno más punteros de estado del proveedor (previous_response_id); protocolo de cliente e identificador de receta pública; la procedencia y precedencia de las instrucciones de sistema/desarrollador/gateway/receta; mensajes, bloques de contenido, imágenes y texto derivado; herramientas, resultados de herramientas, elección de herramientas y política de herramientas paralelas; modalidades y configuraciones de generación; un registro de pérdidas de compatibilidad; filas de uso y filas de costos separadas por roles; y una traza que cubra la actividad de evidencia, búsqueda, herramienta, costo y rol de modelo.

La justificación práctica es concreta: el tool_result de Anthropic debe seguir inmediatamente a su tool_use coincidente; las salidas de llamadas a funciones de las Respuestas de OpenAI deben reproducirse por call_id; una fachada de Chat no puede preservar completamente la prioridad de los mensajes de desarrollador; Claude Code envía el historial completo sin estado en cada turno, mientras que los clientes basados en Respuestas dependen de un puntero de estado del lado del proveedor. Sin una IR y una suite de compatibilidad que ejercite estos casos directamente, un sistema puede aprobar un benchmark y aun así fallar dentro de un cliente de agente real porque el bucle de herramientas nunca se completa correctamente.

El estado actual de la implementación debe declararse con precisión en lugar de con optimismo: la capa de compatibilidad existe como documentación de protocolo, definiciones de IR de adaptador, accesorios de contrato de gateway, un planificador de turnos, un escritor de stream, accesorios de herramienta/evidencia y una suite de pruebas de compatibilidad agregada. Es un esqueleto de compatibilidad offline, suficiente para restringir formas de protocolo, brechas de superficie y evitar la deriva temprana del diseño, pero aún no es un gateway de producción en vivo. Aún no incluye ejecución real de proveedor a escala, una superficie de producto de streaming orientada al cliente, ejecución de herramientas en vivo, autenticación/tenencia de producción o un backend de traza persistente. El descubrimiento de modelos públicos está diseñado para exponer solo identificadores de recetas públicas con nombres de espacio; cualquier solicitud de ID de modelo no pública o sin nombre de espacio debería fallar cerrada (ej. model_not_public) en lugar de permitir que un cliente omita los límites de receta, costo o traza.

8. Modelo de control de uso de herramientas

La llamada a herramientas multi-modelo es la parte operativamente más peligrosa de cualquier extensión de agente de codificación de este sistema. Si varios modelos pueden emitir llamadas a herramientas independientemente en el mismo turno, el resultado puede ser ediciones de archivos duplicadas, llamadas a API externas duplicadas, cargos duplicados, escrituras concurrentes, comandos de shell conflictivos o exposición de credenciales. El modelo de control adoptado es deliberadamente restrictivo:

• Un turno tiene, por defecto, exactamente un propietario de herramienta activo.
• Otros modelos pueden actuar como revisor o crítico y pueden proponer cambios, pero no pueden ejecutar herramientas.
• El texto con forma de herramienta en la salida de un modelo no es, por sí mismo, autoridad de ejecución.
• Cada llamada a herramienta se normaliza en una ToolCall IR canónica antes de que se tome cualquier decisión de ejecución.
• Un programador clasifica cada llamada como executable, advice_only, blocked o requires_approval.
• Las llamadas de solo lectura, lectura de red y solo cómputo pueden ejecutarse concurrentemente en un grupo paralelo bajo condiciones seguras.
• Las llamadas de escritura, escritura de shell, pago, credenciales y clase destructiva se serializan y se aprueban por defecto.
• Los resultados de las herramientas se reproducen determinísticamente de vuelta a la forma esperada del protocolo de destino.
• El JSON parcial nunca se ejecuta; incluso el JSON bien formado debe pasar las comprobaciones de esquema, efectos secundarios, aprobación y propietario.

Esta es una desviación significativa de las demostraciones típicas de agentes múltiples, donde varios agentes pueden intentar "resolver" un problema concurrentemente. Una receta de codificación orientada a la producción requiere disciplina de roles sobre la seguridad de la ejecución: un revisor puede señalar que un parche propuesto romperá una suite de pruebas, pero no puede ejecutar un comando de shell destructivo. Un propietario de herramienta puede iniciar una edición de archivo o comando de shell, pero su salida aún es verificada por el gateway antes de la ejecución.

Esto también restringe cómo deben leerse las etiquetas de capacidad de herramientas de la biblioteca de modelos: una etiqueta de "uso de herramientas" significa que un modelo puede expresar plausiblemente una llamada a herramienta, no que esté autorizado para ser un propietario de herramienta de producción. La promoción al estado de propietario requiere pasar una suite de compatibilidad que cubra argumentos de herramientas en streaming, estabilidad de ID de herramienta, reparación de JSON mal formado, reproducción de resultados de herramientas, política de herramientas paralelas, contabilidad de uso y forma de error. Un caso extremo relacionado es el "rescate" de herramientas en línea: algunos proveedores emiten llamadas a herramientas como texto de asistente (bloques XML/JSON, etiquetas de función privadas, argumentos de objeto o doblemente codificados). La capa de adaptador puede detectar y reparar estos dialectos, pero la reparación solo produce una ToolCall IR candidata; no otorga autoridad de ejecución, está limitada solo al texto de respuesta del propietario actual (nunca al texto del usuario, resultados de herramientas, notas del revisor o la respuesta fusionada final), y una llamada reparada aún debe pasar las puertas de propietario, esquema, efectos secundarios, aprobación, paralelismo e idempotencia. El JSON mal formado repetido debería fallar la comprobación de compatibilidad de ese propietario para el turno en lugar de ejecutarse silenciosamente.

9. Visión y búsqueda web: Justicia vs. Experiencia de producto

Las rutas de evaluación y producto divergen intencionalmente aquí. La prueba de benchmark utiliza evidencia compartida y reproducible; las solicitudes de producción pueden usar búsqueda nativa o visión, pero solo cuando son rastreables.

La búsqueda se maneja a través de tres rutas distintas: shared_evidence (un paquete externo de búsqueda/obtención/lectura reproducible y propiedad de Fusion, obligatorio para ejecuciones de prueba del conjunto de investigación weighted-100, comparaciones de líneas base sólidas, pruebas canary de actualización de modelos y re-ejecuciones finales), native_search (la propia capacidad de búsqueda/navegación/fundamentación de un modelo o proveedor), y external_search (herramientas externas rastreables como obtención, lectura de navegador o extracción de documentos). La búsqueda nativa no está prohibida; puede mejorar la experiencia del producto, pero no puede respaldar una afirmación de benchmark justa, porque si el comportamiento de búsqueda, las fuentes recuperadas y el rastro de citas de un modelo son opacos, la comparación deja de ser una comparación de misma tarea.

La visión sigue la misma lógica. La visión nativa y el texto derivado de OCR/captura no son entradas equivalentes, y una comparación entre modelos con diferente visibilidad de una imagen no es una comparación de visión justa. La traza registra la visibilidad de cada modelo explícitamente como native_image, derived_text o none. El patrón de producción recomendado es un híbrido: los modelos primarios pueden usar visión nativa mientras que los revisores de menor costo trabajan a partir de texto derivado; las tareas de hechos actuales usan por defecto búsqueda/obtención externa, y la búsqueda nativa solo se permite una vez que una ruta ha pasado una prueba de capacidad y produce una traza completa. La evaluación, sin embargo, siempre usa por defecto evidencia compartida y un paquete de evidencia con hash.

10. Biblioteca de modelos como esquema de selección consciente de roles

El catálogo de modelos que subyace a TokenLab Fusion ha pasado de una tabla de capacidades plana a un esquema de selección en capas con campos para nivel de costo, roles de Fusion, etiquetas de capacidad, métricas de selección, perfil de enrutamiento y pista de evaluación recomendada. Esto refleja una realidad de producto que un ranking único de "qué tan fuerte es este modelo" no captura: un modelo puede ser un excelente revisor de codificación y un pobre panelista de investigación de baja latencia; un modelo puede ser económico pero tener IDs de llamada a herramientas inestables; un modelo puede llevar una etiqueta de capacidad de visión nativa sin tener aún evidencia de traza suficiente para una evaluación restringida por justicia.

Capa	Rol representativo	Significado del producto
Barato siempre activo	candidatos a panel/revisor/juez de bajo costo	Composición de panel predeterminada, promovido solo mediante evidencia canary emparejada
Actualización de razonamiento sólido	escalada de tareas difíciles	Rol de synth/validador/juez para tareas difíciles
Especialista en codificación/agente	bucle de herramientas, escala de repositorio, revisión de front-end	Candidatos a propietario de herramienta y revisor de agente de codificación
Especialista en visión/búsqueda	flujos de trabajo de producto pesados en imagen/búsqueda	Requiere prueba de traza antes del uso restringido por justicia
Retención de contexto ultra largo	diagnóstico de repositorio/paquete de evidencia enorme	No es un miembro de panel predeterminado
Comparador de caja negra	sistemas multi-agente del lado del proveedor	Solo punto de referencia; la atribución interna de Fusion no puede derivarse de él

El juicio actual sobre el ancla premium retirada merece una declaración explícita: el modelo histórico premium de Gemini Pro que ancló la prueba weighted-100 ha sido retirado de la planificación de recetas de costo de producto activo, y un modelo de nivel flash de Gemini de menor precio también se eliminó del plan predeterminado debido a precios de salida que no se ajustan al perfil de costo de la receta objetivo. Esto no revisa el resultado de la ejecución de investigación weighted-100, esa prueba se mantiene como se registró, pero significa que la prueba y la receta de envío prevista no son actualmente el mismo sistema, que es precisamente por lo que la prueba canary sin Gemini premium es el siguiente paso de evidencia requerido, no uno opcional.

11. Puertas de actualización de la biblioteca de modelos

Una preocupación operativa recurrente es si cada cambio de modelo requiere una re-ejecución completa de 100 tareas. La respuesta adoptada por el programa es el gating proporcional al riesgo en capas en lugar de cualquiera de los extremos (re-ejecuciones completas ciegas en cada cambio, o sustitución ciega de la misma familia sin evidencia):

1. Humo de contrato: confirmar ruta, precios, streaming, ventana de contexto, límites de salida, modalidad y banderas de herramienta/búsqueda/visión.
2. Suite de compatibilidad: ejercitar Chat OpenAI, Respuestas OpenAI, Mensajes Anthropic, llamada a herramienta, resultado de herramienta, herramienta paralela, uso, error y manejo de stream.
3. Evaluación centinela: ejecutar un pequeño conjunto específico de dominio adaptado al rol reclamado del modelo (ej. suficiencia de fuente de finanzas, bucle de herramienta de codificación, revisión visual de front-end).
4. Canary emparejado: comparar frente a la receta actual en IDs de tarea idénticos para calidad, costo, latencia y tasa de fallos.
5. Ejecución completa de 100 tareas: reservada para candidatos que podrían cambiar la receta predeterminada o una afirmación de línea base sólida.

Incluso una actualización de la misma familia aparentemente menor requiere pasar por este embudo: los precios, el comportamiento de llamada a herramientas, el streaming y la calidad emparejada necesitan confirmación independiente en lugar de inferirse de un nombre de familia de modelo compartido. Esta es también la razón por la cual el manifiesto de 100 tareas no se ejecuta continuamente; está reservado para la confirmación final, mientras que los cambios de modelo diarios se rigen por las puertas más baratas y rápidas anteriores.

12. Trabajo relacionado y qué se reutiliza (y qué no)

El programa se basa en varias direcciones de investigación y herramientas públicas sin adoptar sus objetivos al por mayor. Mixture-of-Agents motiva la idea de que las salidas de modelos más débiles pueden condicionar útilmente a un sintetizador más fuerte, pero los hallazgos de hinchazón del panel en la Sección 4 advierten contra la estratificación sin ablación. LLM-Blender contribuye a la estructura de generación de candidatos, clasificación por pares y fusión generativa que se asemejan a las etapas de panel/juez/síntesis, aunque ningún clasificador entrenado dedicado reemplaza actualmente al juez basado en rúbricas. FrugalGPT y RouteLLM motivan la cascada y el enrutamiento conscientes de los costos, pero el problema de enrutamiento aquí es de múltiples roles (panel, síntesis, juez, validador, estrategia de búsqueda, propietario de herramienta pueden enrutar independientemente cada uno), no una elección de modelo binaria única. Las herramientas de arnés de evaluación como Inspect AI, OpenAI Evals, Promptfoo y Ragas informan el patrón de ingeniería de un ciclo de evaluación sistemático y amigable con CI, pero ninguno de ellos sustituye al manifiesto ponderado fijo, las comprobaciones de suficiencia de fuentes, las filas de costos separadas por roles o la estructura de prueba emparejada ponderada por dominio utilizada aquí.

13. Limitaciones

Limitación	Estado actual	Por qué importa
Dependencia de ancla premium	La prueba weighted-100 usó un modelo histórico premium de Gemini Pro como synth/juez/validador	Prueba el techo de la receta, no la receta de costo de producto prevista
Re-ejecución final incompleta	Re-ejecución solo de Fusion a 20/100 tareas, 20/20 compatibles con tiempo de ejecución	La reproducibilidad sin costo de línea base aún no está totalmente confirmada
Sin datos públicos de auditoría humana o acuerdo entre evaluadores	Los resultados de auditoría humana y acuerdo entre evaluadores aún no se han publicado ni hecho públicos para este pipeline de evaluación	La confiabilidad y consistencia de las puntuaciones automatizadas en relación con el juicio humano permanecen sin verificar, limitando la confianza en la interpretación absoluta de la puntuación
Desventaja de latencia	1.23x vs. gpt-5.5, 2.15x vs. claude-opus-4-8	Puede ser aceptable para investigación profunda, probablemente inaceptable para agentes de codificación interactivos
Validador consciente de rúbricas	El validador ve la rúbrica/lista de verificación de puntuación	Las comparaciones deben revelar esto; no comparable directamente a sistemas ciegos a rúbricas
Advertencias de fuentes de Finanzas	8 advertencias de alta severidad finance:needs_more_sources	La suficiencia de fuentes en Finanzas no está resuelta a pesar de las grandes deltas de puntuación
Inferencia de capacidad nativa	Las etiquetas de capacidad de búsqueda/visión no son prueba de soporte de traza de grado de producción	Requiere sondas por ruta antes de cualquier uso de evaluación restringido por justicia
Madurez de la capa de compatibilidad	Esqueleto offline (IR, accesorios, contrato de enrutador, planificador, escritor de stream)	Aún no es un gateway de producción en vivo con ejecución real de proveedor, autenticación/tenencia o almacenamiento de traza persistente
Volatilidad de precios/ruta	La corrección de precios de DeepSeek V4 Pro ya cambió una decisión estratégica	El nivel de la biblioteca de modelos debe ser re-verificado a medida que cambian los precios y el comportamiento de la ruta

14. Preguntas frecuentes

¿El resultado de 100 tareas significa que TokenLab Fusion supera a GPT-5.5 y Claude Opus 4.8 en general?

El resultado emparejado se mantiene específicamente en el manifiesto de investigación weighted-100 fijo, utilizando evidencia compartida y contabilidad de costos separada por roles, con gpt-5.5 y claude-opus-4-8 fuera del panel de Fusion. Es evidencia sólida y amplia en dominios dentro de ese alcance, no una afirmación general independiente del tipo de tarea, condiciones de evidencia o composición del manifiesto.

¿Por qué importa el ancla de Gemini Pro si la delta de puntuación ya es grande?

La delta fue producida por una receta que utilizó un modelo histórico premium de Gemini Pro para síntesis, juzgar y validar. Esa configuración establece lo que puede lograr la estructura de la receta, pero no es el perfil de costo que la ruta de producto pretende enviar. Hasta que no se ejecute una configuración sin Gemini premium como prueba canary emparejada frente a los mismos IDs de tarea, la calidad lograda y el costo de envío previsto se prueban por separado, no juntos.

¿Es un costo menor por llamada lo mismo que un costo menor por unidad de calidad?

No, y ambos se reportan por separado por esta razón. Los multiplicadores de costo 0.71x y 0.69x describen el costo bruto frente a las dos líneas base; los ratios de puntuación por dólar 2.26x y 3.06x describen la calidad ajustada por costo. Ambos son necesarios, porque un sistema puede ser más barato por llamada y aun así puntuar peor, o más caro por llamada y aun así ser más eficiente en costos por unidad de calidad; esta evaluación reporta ambos explícitamente en lugar de colapsarlos.

¿Por qué importa la ablación del validador para este resultado?

La etapa de validador/reescritura consciente de rúbricas produjo el cambio de calidad único más grande medido en este programa (delta emparejada +51.81 en una expansión de 20 tareas), a aproximadamente 2.14x de costo y 1.89x de latencia frente al control de núcleo rápido. Cualquier comparación entre recetas, o entre Fusion y una línea base, necesita revelar si la etapa de validador está activa, porque cambia tanto el perfil de costo como el encuadre de justicia (el validador tiene visibilidad de las rúbricas de puntuación).

¿Está TokenLab Fusion listo para ejecutarse dentro de un cliente de agente de codificación real hoy?

No. La arquitectura de protocolo y control de uso de herramientas (IR canónica, suite de compatibilidad, modelo de propietario de herramienta) existe como un esqueleto de compatibilidad offline con mapeos de protocolo y accesorios documentados, pero aún no incluye un gateway de producción en vivo, ejecución real de proveedor a escala, autenticación/tenencia o almacenamiento de traza persistente. La prueba de Investigación Profunda y la línea de Agente de Codificación se evalúan en diferentes líneas de tiempo, y la línea de codificación aún no ha completado su primera fase de validación de muestra pequeña.

15. Cierre de la investigación

Lo que está probado

En un manifiesto multidominio fijo, con hash y ponderado de 100 tareas, utilizando evidencia compartida y contabilidad de costos separada por roles, una receta multi-modelo equipada con validador logró una delta de puntuación media emparejada de +32.60 sobre gpt-5.5 y +45.63 sobre claude-opus-4-8, a 0.71x y 0.69x de costo respectivamente, con cero fallos de llamada en 799 filas de costos. La validación consciente de rúbricas se confirma como la palanca de calidad única más grande probada, con una delta emparejada de +51.81 sobre un control de núcleo rápido. Las deltas positivas se mantienen en todos los dominios del manifiesto frente a ambas líneas base, lo que indica que la ganancia no está concentrada en un tipo de tarea.

Lo que permanece restringido

La re-ejecución final solo con Fusion de la receta ganadora congelada está incompleta (20 de 100 tareas en la última comprobación) y debe alcanzar la cobertura total con una auditoría de preparación limpia antes de que la prueba pueda llamarse reproducible de principio a fin. La receta que produjo la prueba depende de un ancla histórica premium de Gemini Pro que la ruta de costo de producto pretende retirar; aún no existe evidencia emparejada para la sustitución prevista sin Gemini premium. La latencia sigue siendo un compromiso de producto no resuelto, particularmente para cualquier aplicación de agente de codificación. La suficiencia de fuentes de Finanzas conlleva ocho advertencias de alta severidad no resueltas a pesar de una gran ventaja de puntuación en ese dominio. La capa de compatibilidad de protocolo está definida arquitectónicamente pero aún no es un gateway de producción en funcionamiento.

Qué evidencia debe recogerse a continuación

Completar la re-ejecución final solo con Fusion en las 80 tareas restantes y volver a ejecutar la auditoría de preparación para confirmar la reproducibilidad sin costo de línea base en el bucle. Ejecutar una prueba canary emparejada, con el mismo ID de tarea, sustituyendo deepseek-v4-pro para síntesis/validación y glm-5.2 para juzgar en lugar del ancla premium de Gemini Pro, comenzando a pequeña escala antes de cualquier afirmación de manifiesto completo. Cerrar las ocho advertencias de suficiencia de evidencia de Finanzas pendientes con trabajo de puerta de fuente específico de dominio antes de tratar el resultado del dominio de Finanzas como totalmente resuelto. Extender la suite de compatibilidad desde un esqueleto offline hacia la ejecución real del proveedor, y ejecutar una fase de validación de agente de codificación de muestra pequeña (del orden de cinco tareas) para probar si la arquitectura de propietario/revisor de herramienta produce una ventaja medible de panel sobre modelo único antes de invertir más en infraestructura de agente de codificación. Cada uno de estos es un experimento siguiente específico y falsable, no un elemento de hoja de ruta general.