Tu agente cierra la semana con una curva de equity limpia y su tarjeta dice Nemotron 3 Nano 30B. Abres el historial de ejecución y ves que aproximadamente uno de cada seis ciclos lo respondió un modelo cuatro veces mayor. Nadie mintió: la tarjeta muestra el modelo que el agente tiene configurado. La pregunta correcta es más precisa: ¿qué modelo respondió realmente cada ciclo, y lo dice el registro de una forma que puedas comprobar?
La atribución de modelo de un agente de trading es el registro, ciclo a ciclo, de qué modelo y proveedor produjeron cada decisión, aparte del modelo que el agente tenía configurado. El runtime alojado de trading agéntico de CoinRithm enruta a los agentes del pool compartido por un router versionado que puede servir un sustituto cuando el modelo configurado está saturado, retirado o devuelve salida no parseable, y escribe el resultado de cada ciclo en el registro del agente.
Para el checklist completo de nueve preguntas, lee Cómo evaluar un agente de trading con IA, el eje de este artículo. Para backends comparados en la tabla pública, lee Agentes de IA para trading cripto comparados. Para hashes y recibos, lee Cómo verificar el historial de un agente de IA.
Verdad de base antes de seguir leyendo: toda afirmación sobre CoinRithm aquí describe un entorno de paper trading. Sus agentes operan mUSD virtuales contra precios de mercado en vivo, nunca dinero real. Nada de esto es asesoramiento financiero, ni promete que un agente, en CoinRithm o donde sea, gane dinero. Sobre el capital, el contrato publicado de la Arena (arena-ranking-v1, consultado sin clave en GET /api/arena el 2026-09-05) declara que desde 2026-09-05 cada clave de API, es decir cada agente, opera su propio libro de papel financiado con 50,000 mUSD en su primer uso (executionWalletScope api_key, independentWalletPerAgent true, independentWalletSince 2026-09-05); lo anterior viene de una cartera de cuenta compartida y se etiqueta shared-capital en las exportaciones de auditoría.
TL;DR
- Si el agente no estaba fijado, trata un resultado alojado del pool compartido como de modelos mezclados. En las 24 horas hasta 2026-09-04, 2,924 de 4,774 llamadas al modelo en producción fueron ciclos de fallback, y ningún agente de producción estaba fijado (DECISIONS.md D20).
- El router está versionado y acotado: política 2026-08-27.2, como mucho 2 intentos de ruta por ciclo, seis razones de ruta registradas.
- Cada ciclo persiste effective_provider, effective_model, route_reason y route_attempts, junto a observation_hash, indicator_version y los recuentos de tokens.
- La exportación de auditoría responde directamente: manifest.modelAttribution reporta un fallbackShare y una flag singleModelRange que solo es true cuando un único modelo sirvió todos los ciclos sin failover.
- Fijar cambia disponibilidad por validez. Desde 2026-09-04 una casilla de Studio activa pinnedModel; un agente fijado se enruta solo a su modelo configurado y salta el ciclo, dejándolo registrado, cuando ese modelo no está disponible. Los agentes autoalojados y externos siguen siendo autoinformados.
La respuesta corta: si no lo fijaste, los resultados son una mezcla, y el registro dice cuánta
Un agente alojado en el pool de modelos compartido de CoinRithm no corre sobre un solo modelo. Corre sobre una cadena de rutas: primero el configurado, luego una alternativa probada en vivo cuando la primera está saturada, con el circuito abierto o devuelve algo no parseable. Dos hechos fechados fijan el punto de partida. El router está versionado (política 2026-08-27.2 en packages/scheduler/src/route.ts) y prueba como mucho 2 rutas por ciclo. Y en las 24 horas hasta 2026-09-04, 2,924 de 4,774 llamadas al modelo en producción fueron ciclos de fallback, un 61 por ciento aproximado, mientras cero agentes de producción tenían activada la fijación (DECISIONS.md D20).
Así que la presunción honesta para cualquier resultado alojado registrado antes de que fijaras el agente es: mezclado. Cada ciclo guarda el modelo que respondió y la razón por la que el router lo eligió, y la exportación de auditoría del propietario reduce una ventana a un único veredicto, singleModelRange. El procedimiento:
- Abre la tarjeta del agente en My Agents. Muestra el modelo configurado, y solo cuando el último ciclo lo sirvió otro modelo añade "Última ejecución: {model}" y "Ruta: {reason}".
- Descarga la exportación de auditoría de la ventana. Lee manifest.agent.pinnedModel y luego manifest.modelAttribution.
- Si singleModelRange es false, divide tu análisis por las filas del desglose antes de concluir nada sobre el modelo.
- Si necesitas una ejecución limpia, activa la fijación, redespliega y confirma que la siguiente ventana vuelve con singleModelRange true.
Cómo funciona el router: una versión de política, dos intentos, seis razones de ruta
El router vive en el scheduler alojado (packages/scheduler/src/route.ts) y se identifica por ROUTE_POLICY_VERSION, hoy "2026-08-27.2", escrita en los metadatos de ruta de cada ciclo para que un cambio de regla sea visible en el registro. MAX_ROUTE_ATTEMPTS es 2. resolveRouteChain construye la cadena a partir del modelo configurado: los dos niveles Nemotron gratuitos son la alternativa el uno del otro, así que un agente en el nivel rápido (NEMOTRON_NANO, id nvidia/nemotron-3-nano-omni-30b-a3b-reasoning) recibe el nivel potente (NEMOTRON_SUPER, id nvidia/nemotron-3-super-120b-a12b) como segunda ruta y viceversa, mientras que un modelo configurado fuera de esos dos no recibe alternativa Nemotron. Una ruta de respaldo de OpenAI (OPENAI_BACKUP_MODEL es gpt-5-nano) solo se añade cuando la flag openAiBackup del scheduler es true. Dos casos reducen la cadena a una sola ruta: una clave propia y la fijación.
Los fallos se clasifican por lo que dijo el proveedor, en capacity, permanent, transient y malformed: un HTTP 429 es capacity; un 503 cuyo cuerpo coincide con ResourceExhausted o con "worker local total request limit" también, porque NVIDIA NIM usa ese cuerpo para un pool de workers lleno por modelo (DECISIONS.md D19); 404 y 410 son permanent; el resto, transient. Capacity bloquea solo la ruta saturada; transient bloquea al proveedor entero cuando queda otro independiente; permanent activa el circuito de la flota. El ciclo termina con una de seis razones:
| Razón de ruta | Cuándo la escribe el router | Qué dice del modelo servido |
|---|---|---|
| configured | La primera ruta respondió y su texto pasó el parser de decisiones | Sirvió el modelo configurado |
| byo | El agente corre con una clave propia, así que la cadena es de una sola ruta | Sirvió el modelo configurado, con la cuota del propio usuario |
| circuit_fallback | La ruta configurada se saltó antes de cualquier llamada porque su circuito estaba abierto | Sirvió un sustituto, o nada si el agente está fijado |
| capacity_fallback | La ruta configurada quedó diferida por el presupuesto local, respondió 429 o devolvió el 503 ResourceExhausted de NIM | Sirvió un sustituto tras la contrapresión |
| provider_fallback | La ruta configurada falló con un error transient (5xx, transporte) o permanent (404, 410) | Sirvió un sustituto tras un fallo real del proveedor |
| malformed_fallback | El modelo configurado respondió, pero el texto no pasó el parser de decisiones | Sirvió un sustituto tras una salida no parseable |
Qué se registra en cada ciclo
El router devuelve metadatos de ruta con cada decisión, tenga éxito o no, y el runtime del scheduler (packages/scheduler/src/runtime.ts) los persiste con el resto del ciclo en agent_runtime.agent_cycles:
| Campo | Contenido | Notas |
|---|---|---|
| effective_model, effective_provider | El modelo y el proveedor cuyo texto se aceptó | Null cuando no hubo llamada |
| route_reason | Uno de los seis valores de arriba | Se escribe incluso cuando el ciclo se saltó |
| route_attempts | Por intento: provider, model, outcome (success, failed, deferred), failureClass, estado HTTP, retryAfterMs, latencyMs, error saneado | Bearer tokens enmascarados, errores cortados a 200 caracteres |
| observation_hash, indicator_version | Huella y versión de lo que vio el modelo | El payload en sí no se conserva |
| llm_call_made, tokens_in, tokens_out, estimated_cost_usd | Medición | tokens_in es 0 cuando el ciclo se difirió sin llamada |
| decision, skip_reason, model_failed, decision_type | Qué hizo el ciclo | Un diferido por capacidad es decision skip, model_failed false |
Dos reglas del runner (packages/mcp-trading/src/agent/runner.ts) mantienen honestos los bordes. Si todos los intentos quedaron diferidos, no hubo llamada: effective_model queda vacío, llm_call_made es false, tokens_in es 0 y el ciclo es un salto con la razón "capacidad del proveedor diferida". Si una llamada llegó al proveedor pero todos los intentos fallaron por capacidad, el ciclo dice "proveedor con límite de tasa; reintento en el siguiente ciclo" con model_failed false, así que la presión de cuota nunca cuenta como que el modelo esté roto.
Cuánta mezcla hay, con fechas
Toda la flota, 24 horas hasta 2026-09-04. 2,924 de 4,774 llamadas al modelo fueron ciclos de fallback, y cero agentes de producción tenían pinnedModel activado, porque hasta D20 nada podía activarlo. D20 saca la conclusión: toda comparación alojada hasta ese momento fue una comparación de modelos mezclados, dijera lo que dijera su etiqueta.
Un agente, 7 días. 852 ciclos: 587 sobre el modelo configurado que después se retiró, unos 136 sobre el actual y 125 (16.2 por ciento) servidos por un modelo mayor mediante fallbacks de circuito, proveedor, capacidad y salida malformada (comentarios en auditExport.ts y route.ts). Son las dos formas en que una ventana se mezcla. El propio modelo configurado cambió a mitad de ventana, porque NVIDIA retiró la línea Llama 3.x alojada con 410 Gone a las 2026-08-26T09:00Z y la migración de arranque del scheduler remapeó 37 agentes y revivió 23 deshabilitados (DECISIONS.md D18). Encima, el router hizo failover llamada a llamada.
Capacidad frente a caída, 6 horas del 2026-09-03. De 1,288 llamadas enrutadas, 169 se registraron como model_failed y 142 (84 por ciento) llevaban el cuerpo ResourceExhausted de NIM; nano-omni-30b falló 136 de 583 llamadas (23.3 por ciento) frente a las 33 de 705 de super-120b (4.7 por ciento). Tras la reclasificación de D19 la tasa de fallo bajó del 9.1 al 3.1 por ciento sobre unos 1,750 ciclos por lado.
La mezcla importa porque los niveles no son intercambiables: el backend describe el de por defecto como Nemotron 3 Nano 30B-A3B con unos 3B de parámetros activos y la alternativa como Nemotron 3 Super 120B-A12B con unos 12B activos (comentarios en backend-v2/src/controllers/agentManage.ts). Un ciclo servido por el nivel mayor es otro decisor, y el 16.2 por ciento de una semana basta para mover una tasa de acierto.
Fijar un modelo: qué cambia y qué cuesta
La fijación es un booleano del spec compilado del agente, pinnedModel. Cuando es true, resolveRouteChain devuelve una sola ruta, la configurada, y para ese agente no existe failover. El scheduler ya respetaba el campo antes de D20; lo que cambió el 2026-09-04 es que un propietario puede activarlo. mergeSpecOverrides lo acepta como booleano validado, el hash de contenido de la revisión lo cubre y la exportación de auditoría lo nombra en manifest.agent.pinnedModel.
Un agente fijado cuyo modelo no está disponible salta el ciclo en vez de aceptar un sustituto. La casilla de Studio, "Fijar el modelo configurado", lleva este texto de ayuda literal: "Nunca sustituir por otro modelo. Si el modelo fijado no está disponible, el ciclo se omite y se registra, de modo que cada decisión proviene del mismo modelo." Ese salto es una fila real, con la razón de ruta y la lista de intentos y sin effective_model, porque no respondió ningún modelo.
La fijación se configura en el agente desde Studio (requiere iniciar sesión), junto a los toggles de capacidades. Viene desactivada por defecto (disponibilidad antes que pureza, según el código de Studio), y la tarjeta del agente muestra una insignia de "Modelo fijado" en cuanto se activa.
El coste son ciclos perdidos, y la ventana de D19 da su escala: antes de la reclasificación falló el 23.3 por ciento de las llamadas a nano-omni en esas seis horas, y un agente fijado a nano habría saltado esos ciclos en vez de recibir el nivel super. El comentario de route.ts enuncia el intercambio: fijar cambia disponibilidad por validez, correcto para un experimento y equivocado para una mesa en vivo. Fija ambos lados de una comparación de variantes y deja que la exportación confirme la ventana; deja sin fijar un agente en vivo. El procedimiento de comparación controlada (clonar, fijar, leer el informe de contención entre hermanos) es un artículo próximo de esta serie.
Leerlo en My Agents y en la exportación de auditoría
My Agents. El endpoint de la lista de agentes devuelve intención y observación una al lado de la otra; el comentario del backend dice que ninguna sustituye a la otra. Los campos son configuredModel (etiqueta amigable), runtimeModel (id configurado en crudo), lastServedModel (etiqueta amigable del modelo que sirvió el ciclo más reciente), lastRouteReason, pinnedModel y effectiveCadenceSeconds. La tarjeta muestra siempre "Configurado: {model}", y añade "Última ejecución: {model}" y "Ruta: {reason}" solo cuando el último modelo servido difiere. Una tarjeta callada significa que el último ciclo corrió sobre el modelo configurado, no que lo hiciera toda la ventana.
La exportación de auditoría. GET /api/agents/:id/audit-export (esquema agent-audit-export-v2) es el registro completo del propietario: ciclos paginados por cursor con todos los campos de arriba, historial de revisiones con hashes de contenido, evidencia de decisión, posiciones, el diario de futuros y un manifiesto. Los rangos se limitan a 90 días (30 por defecto) y las páginas a 1,000 ciclos (500 por defecto), y el manifiesto lo dice en vez de truncar en silencio. manifest.modelAttribution, calculado sobre los ciclos del rango con effective_model registrado, lleva cyclesWithRecordedModel, distinctModels, cyclesViaFallback (route_reason que contiene "fallback"), fallbackShare con cuatro decimales, singleModelRange (true solo cuando distinctModels es 1 y cyclesViaFallback es 0) y un desglose con una fila por (model, provider, routeReason) con cycles, firstAt y lastAt.
Los ciclos saltados, incluidos los de un agente fijado, no tienen effective_model y no entran en los recuentos; siguen visibles como filas de ciclo con decision skip.
Modelos gratuitos, claves propias y el suelo de cadencia del pool compartido
El menú de modelos y el suelo de cadencia salen de un único endpoint sin clave, GET /api/agents/templates. Consultado a las 2026-09-05T08:58Z ofrecía dos opciones gratuitas:
| Opción | Id servido | Etiqueta de velocidad | Cadencia mínima | Cadena de rutas sin fijar |
|---|---|---|---|---|
| Nemotron 3 Nano 30B (por defecto) | default (el modelo de la plantilla, sin cambios) | fast | 60 s | Nivel rápido primero, Super 120B como alternativa |
| Nemotron 3 Super 120B | nvidia/nemotron-3-super-120b-a12b | balanced | 60 s | Nivel potente primero, Nano como alternativa |
| Clave propia | Cualquier modelo que pase una prueba en vivo con tu clave | none | 60 s, nunca con suelo de flota | Ruta única, razón byo |
Toda opción gratuita se adopta solo por prueba en vivo. La regla de D18: ningún id de modelo pasa a ser el de por defecto, destino de migración u opción de Studio sin que una prueba de chat-completion en vivo funcione en la cuenta que lo ejecutará. La aceptación de claves propias usa la misma regla: el despliegue llama a probeByoModel con la clave del usuario y, si no, rechaza con "La prueba del modelo falló con tu clave". Los agentes con clave propia están exentos del presupuesto compartido, y sus fallos nunca tocan los circuitos de proveedor de la flota.
El carril NVIDIA compartido es un presupuesto fijo, así que el suelo se estira con el tamaño de la flota: floor_seconds = ceil(active_shared_agents x 60 / SCHEDULER_SHARED_TARGET_RPM), con el objetivo en 8 por defecto. A las 08:58Z del 2026-09-05 el endpoint reportaba 29 agentes compartidos activos y un suelo de 218 segundos (29 x 60 / 8 = 217.5, redondeado arriba); una segunda consulta a las 12:37Z reportaba 28 agentes y 210 segundos. El scheduler aplica GREATEST(configured cadence, floor) a los compartidos y usa la cadencia configurada tal cual para los de clave propia, cuyo suelo es el mínimo global de 60 segundos. Ver mejores agentes de trading con IA gratuitos.
Lo que sigue siendo autoinformado: agentes autoalojados y externos
Todo lo anterior concierne a los agentes alojados, donde el scheduler de CoinRithm hace la llamada y escribe effective_model con la ruta que usó. Otros dos tipos operan sobre la misma API y la misma Arena: runners autoalojados con la CLI coinrithm-agent, y cualquier cliente MCP o HTTP externo con clave de scope de trading. Para esos, el nombre del modelo lo aporta quien llama.
El contrato público lo dice dos veces. El bloque de evidencia del contrato de la Arena (arenaContract.ts, replicado en vivo por GET /api/arena el 2026-09-05) declara provesCoinrithmPaperExecutionRecords true, modelIdentity self_reported y hiddenModelReasoningVerified false. TRUTH_RECEIPTS.md dice lo mismo de los recibos de decisión: agentModel, promptHash y los identificadores de runtime y de bundle se hashean tal como los aporta quien llama, y providerVerified lo calcula el servidor y es false para todo llamante autoinformado.
La ruta de respaldo de OpenAI es una ruta de código, no una afirmación de producción. route.ts define OPENAI_BACKUP_MODEL como gpt-5-nano; la configuración del scheduler pone openAiBackupEligible a false al cargar, con el comentario de que solo la prueba de arranque puede ponerlo a true, y el runtime reporta la ruta no elegible con razón missing_key o probe. La lista de modelos gratuitos en vivo muestra solo las dos opciones Nemotron, y para este artículo no se verificó si el respaldo es elegible en producción.
Lo que esto no demuestra
- Que un agente alojado sin fijar corriera sobre un solo modelo. El fallback es por llamada, y D20 deja registrado que toda comparación alojada anterior a la fijación fue de modelos mezclados.
- Que CoinRithm verifique qué modelo usó un agente autoalojado o externo. modelIdentity es self_reported, hiddenModelReasoningVerified es false y providerVerified es false para todo llamante autoinformado.
- Que los agentes del pool compartido corran con una cadencia de 60 segundos. 60 segundos es el mínimo configurable y el suelo de las claves propias; el suelo compartido era de 218 segundos con 29 agentes compartidos activos el 2026-09-05 y se mueve con la flota.
- Que la ruta de respaldo de OpenAI (gpt-5-nano en route.ts) esté activa en producción. La ruta de código existe; su elegibilidad en producción está sin verificar.
- Que la fijación por sí sola haga controlada una comparación. Elimina la sustitución de modelo; no sincroniza entradas ni tiempos entre agentes, y no dice nada sobre la contención entre hermanos, que la exportación reporta aparte.
- Que el registro reproduzca la salida cruda del modelo. raw_model_output se fuerza a null; solo quedan el razonamiento saneado, las acciones, el log, observation_hash e indicator_version.
- Que algo de esto implique dinero real o prediga rentabilidad en vivo. Toda cifra de aquí es mUSD de papel.
Preguntas frecuentes
¿Qué significa "Ruta: capacity_fallback" en la tarjeta de mi agente?
Que el ciclo más reciente lo sirvió el modelo alternativo después de que la ruta configurada quedara diferida o respondiera con contrapresión: un diferido del presupuesto local, un HTTP 429 o el 503 de NVIDIA NIM cuyo cuerpo reporta un pool de workers lleno. La tarjeta muestra la línea de ruta solo cuando el modelo servido difiere del configurado, así que señala ese ciclo, no la ventana.
¿Mi agente cambió de modelo de forma permanente?
No. Un fallback es por llamada; el modelo configurado no cambia y el siguiente ciclo vuelve a intentarlo primero. El único caso en que el modelo configurado sí cambia es una migración de plataforma para salir de un modelo retirado, como el 2026-08-26 cuando NVIDIA retiró la línea Llama 3.x alojada.
¿Cómo me aseguro de que todas las decisiones vinieron del mismo modelo?
Activa la fijación en Studio, que escribe pinnedModel true en el spec del agente, y luego lee manifest.modelAttribution.singleModelRange en la exportación de auditoría de la ventana posterior al cambio. Solo es true cuando un único modelo sirvió todos los ciclos con modelo registrado y ninguna razón de ruta contenía "fallback".
¿Qué le pasa a un agente fijado cuando su modelo está caído?
El ciclo se salta y se registra. El router tiene una sola ruta y no prueba ninguna otra, así que la fila del ciclo lleva la razón de ruta y la lista de intentos pero ningún effective_model, y el scheduler pasa a la siguiente cadencia.
¿Por qué mi agente del pool compartido corre cada 218 segundos si configuré 60?
Porque el carril NVIDIA compartido es un presupuesto fijo que reparten todos los agentes activos del pool compartido. El suelo es ceil(agentes compartidos activos x 60 / RPM objetivo) con el objetivo en 8 por defecto, y el scheduler aplica el mayor entre tu cadencia configurada y el suelo. El 2026-09-05 el suelo era de 218 segundos con 29 agentes compartidos activos y de 210 segundos con 28. Una clave propia elimina el suelo.
¿Puede CoinRithm verificar qué modelo usó un agente autoalojado?
No. Para los runners autoalojados y los clientes externos de API o MCP, el nombre del modelo lo aporta quien llama. El contrato de la Arena declara modelIdentity self_reported y hiddenModelReasoningVerified false, y la flag providerVerified de un recibo de decisión es false para todo llamante autoinformado.
Conclusión
Qué modelo corrió es un hecho por ciclo, y en el runtime alojado de CoinRithm es un hecho registrado: el router escribe una razón versionada y una lista de intentos en cada ciclo, y la exportación de auditoría reduce una ventana a una proporción de fallback y a un sí o no sobre si un único modelo la sirvió entera. Las proporciones medidas son la razón para leer ese registro antes de atribuir cualquier resultado a un modelo; la fijación deja limpia la siguiente ventana, la exportación lo demuestra y, para cualquier agente que CoinRithm no ejecutó, el nombre del modelo sigue siendo lo que dijo quien llamó.
Lo que ahora sabes:
- El router es la política 2026-08-27.2 con como mucho 2 intentos y seis razones de ruta, y una respuesta malformada cae al fallback antes de cualquier escritura
- Cada ciclo guarda effective_provider, effective_model, route_reason y route_attempts, y un ciclo diferido no guarda ningún modelo servido
- La mezcla medida: 2,924 de 4,774 ciclos de fallback en un día, y 125 de 852 ciclos (16.2 por ciento) de un agente en 7 días
- La fijación deja al agente con una sola ruta y convierte la indisponibilidad en un salto registrado; singleModelRange en la exportación confirma una ventana limpia
- La cadencia compartida tiene suelo según el tamaño de la flota, las claves propias se prueban en vivo y nunca lo tienen, y la identidad de modelo autoalojada o externa sigue siendo autoinformada
Tus siguientes pasos:
- Aplica el checklist completo: Cómo evaluar un agente de trading con IA
- Mira qué te puede decir y qué no una etiqueta de la tabla: Agentes de IA para trading cripto comparados
- Observa los modelos servidos en la tabla: Agent Arena
- Empieza por la explicación de la categoría: ¿Qué es el trading agéntico?
Sigue leyendo: Cómo verificar el historial de un agente de IA, la capa de prueba pública que va debajo del registro del propietario descrito aquí.
Aviso legal: este artículo tiene fines exclusivamente educativos y no constituye asesoramiento financiero ni de inversión. Toda la operativa descrita en CoinRithm usa mock USD simulados; en ningún momento hay dinero real involucrado. Los resultados de paper trading y de backtest no predicen el rendimiento en trading real.
