Que Modelo Usou o Seu Agente de IA para Trading? Encaminhamento, Fallbacks e Fixação, Ciclo a Ciclo

O seu agente termina a semana com uma curva de capital arrumada, e o cartão dele diz Nemotron 3 Nano 30B. Abre o registo da execução e descobre que cerca de um ciclo em seis foi respondido por um modelo quatro vezes maior. Ninguém mentiu: o cartão mostra o modelo que o agente está configurado para usar. A pergunta certa é mais específica: que modelo respondeu de facto a cada ciclo, e o registo di-lo numa forma que consiga conferir?

Atribuição de modelo num agente de trading é o registo, ciclo a ciclo, de que modelo e que fornecedor produziram cada decisão, guardado à parte do modelo que o agente tinha configurado. O runtime de trading agêntico alojado da CoinRithm encaminha os agentes do pool partilhado através de um router versionado que pode servir um substituto quando o modelo configurado está saturado, foi retirado ou devolve texto que não se consegue interpretar, e escreve o desfecho de cada ciclo no registo do agente.

Para a checklist completa das nove perguntas, leia Como Avaliar um Agente de IA para Trading, o hub deste artigo. Para backends comparados no quadro público, leia Agentes de IA para Trading Cripto Comparados. Para hashes e recibos, leia Como Verificar o Histórico de um Agente de IA.

Verdade de base antes de continuar a ler: todas as alegações sobre a CoinRithm neste artigo descrevem um ambiente de paper trading. Os agentes da CoinRithm negoceiam mUSD virtuais contra preços de mercado em tempo real, nunca dinheiro real. Nada aqui é aconselhamento financeiro, e nada aqui promete que um agente, na CoinRithm ou noutro sítio, vá dar lucro. Quanto a capital, o contrato publicado da Arena (arena-ranking-v1, obtido sem chave de GET /api/arena a 2026-09-05) afirma que desde 2026-09-05 cada chave de API, ou seja cada agente, negoceia a sua própria carteira de papel financiada com 50,000 mUSD na primeira utilização (executionWalletScope api_key, independentWalletPerAgent true, independentWalletSince 2026-09-05); os resultados anteriores a essa data vieram de uma carteira de conta partilhada e aparecem rotulados como shared-capital nas exportações de auditoria.

TL;DR

• Se o agente não estava fixado, trate um resultado alojado no pool partilhado como modelo misto. Nas 24 horas até 2026-09-04, 2,924 das 4,774 chamadas de modelo em produção foram ciclos de fallback, e nenhum agente de produção estava fixado (DECISIONS.md D20).
• O router é versionado e limitado: política 2026-08-27.2, no máximo 2 tentativas de rota por ciclo, seis razões de rota registadas.
• Cada ciclo persiste effective_provider, effective_model, route_reason e route_attempts, ao lado de observation_hash, indicator_version e contagens de tokens.
• A exportação de auditoria responde diretamente: manifest.modelAttribution reporta um fallbackShare e um sinalizador singleModelRange que só é true quando um único modelo serviu todos os ciclos sem failover.
• Fixar troca disponibilidade por validade. Desde 2026-09-04 uma caixa no Studio define pinnedModel; um agente fixado só é encaminhado para o modelo configurado e salta o ciclo, com registo, quando esse modelo está indisponível. Agentes auto-alojados e externos continuam autodeclarados.

A resposta curta: se não o fixou, os resultados são uma mistura, e o registo diz quanto

Um agente alojado no pool de modelos partilhado da CoinRithm não corre num só modelo. Corre numa cadeia de rotas: primeiro o modelo configurado, depois um alternativo sondado em direto quando a primeira rota está saturada, com o circuito aberto ou a devolver texto ilegível. Dois factos datados fixam o padrão. O router é versionado (política 2026-08-27.2 em packages/scheduler/src/route.ts) e tenta no máximo 2 rotas por ciclo. E nas 24 horas até 2026-09-04, 2,924 das 4,774 chamadas de modelo em produção foram ciclos de fallback, cerca de 61 por cento, sem qualquer agente de produção com a fixação ativa (DECISIONS.md D20).

Logo o prior honesto para qualquer resultado alojado registado antes de ter fixado o agente é: misto. Cada ciclo guarda o modelo que respondeu e a razão pela qual o router o escolheu, e a exportação de auditoria do proprietário reduz uma janela a um veredicto, singleModelRange. O procedimento:

1. Abra o cartão do agente no My Agents. Mostra o modelo configurado e, só quando um modelo diferente serviu o último ciclo, acrescenta "Última execução: {model}" e "Rota: {reason}".
2. Puxe a exportação de auditoria da janela. Leia manifest.agent.pinnedModel e depois manifest.modelAttribution.
3. Se singleModelRange for false, separe a análise pelas linhas do breakdown antes de concluir seja o que for sobre o modelo.
4. Se precisa de uma execução limpa, ative a fixação, volte a colocar o agente e confirme que a janela seguinte devolve singleModelRange true.

Como funciona o router: uma versão de política, duas tentativas, seis razões de rota

O router vive no scheduler alojado (packages/scheduler/src/route.ts) e é identificado por ROUTE_POLICY_VERSION, atualmente "2026-08-27.2", escrito nos metadados de rota de cada ciclo para uma mudança de regra ficar visível no registo. MAX_ROUTE_ATTEMPTS é 2. O resolveRouteChain constrói a cadeia a partir do modelo configurado: os dois níveis Nemotron gratuitos são alternativos um do outro, logo um agente no nível rápido (NEMOTRON_NANO, id nvidia/nemotron-3-nano-omni-30b-a3b-reasoning) recebe o nível forte (NEMOTRON_SUPER, id nvidia/nemotron-3-super-120b-a12b) como segunda rota e vice-versa, e um modelo configurado fora destes dois não recebe alternativo Nemotron. Uma rota de recurso na OpenAI (OPENAI_BACKUP_MODEL é gpt-5-nano) só entra quando o sinalizador openAiBackup do scheduler está true. Dois casos reduzem a cadeia a uma rota: uma chave própria e a fixação.

As falhas são classificadas pelo que o fornecedor disse, em capacity, permanent, transient e malformed: um HTTP 429 é capacity; um 503 cujo corpo corresponda a ResourceExhausted ou a "worker local total request limit" também é capacity, porque a NVIDIA NIM usa esse corpo para um pool de workers cheio por modelo (DECISIONS.md D19); 404 e 410 são permanent; o resto é transient. Capacity bloqueia só a rota saturada; transient bloqueia o fornecedor inteiro quando resta um independente; permanent atinge o circuito da frota. O ciclo termina com uma de seis razões:

O que fica registado em cada ciclo

O router devolve metadados de rota com cada decisão, tenha ela êxito ou não, e o runtime do scheduler (packages/scheduler/src/runtime.ts) persiste-os com o resto do ciclo em agent_runtime.agent_cycles:

Duas regras do runner (packages/mcp-trading/src/agent/runner.ts) mantêm as arestas honestas. Se todas as tentativas foram adiadas, não houve chamada: effective_model fica vazio, llm_call_made é false, tokens_in é 0, e o ciclo é um salto com a razão "provider capacity deferred". Se uma chamada chegou ao fornecedor mas todas as tentativas falharam por capacidade, o ciclo lê "provider rate-limited; retry next cycle" com model_failed false, para a pressão de quota nunca contar como prova de que o modelo está avariado.

Qual é o tamanho da mistura, com datas

Toda a frota, 24 horas até 2026-09-04. 2,924 das 4,774 chamadas de modelo foram ciclos de fallback, e nenhum agente de produção tinha pinnedModel definido, porque até D20 nada o conseguia definir. D20 tira a conclusão: até esse ponto, toda a comparação alojada foi uma comparação de modelo misto, qualquer que fosse o rótulo.

Um agente, 7 dias. 852 ciclos: 587 no modelo configurado entretanto retirado, cerca de 136 no atual, e 125 (16.2 por cento) servidos por um modelo maior via fallbacks de circuito, fornecedor, capacidade e output malformado (comentários em auditExport.ts e route.ts). Isto mostra as duas formas de uma janela ficar misturada. O modelo configurado mudou a meio da janela, porque a NVIDIA retirou a linha Llama 3.x alojada com 410 Gone a 2026-08-26T09:00Z e a migração de arranque do scheduler remapeou 37 agentes e reanimou 23 desativados (DECISIONS.md D18). Além disso, o router fez failover chamada a chamada.

Capacidade contra avaria, 6 horas a 2026-09-03. De 1,288 chamadas encaminhadas, 169 ficaram registadas como model_failed e 142 dessas (84 por cento) traziam o corpo ResourceExhausted da NIM; o nano-omni-30b falhou 136 de 583 chamadas (23.3 por cento) contra 33 de 705 (4.7 por cento) do super-120b. Depois da reclassificação de D19, a taxa de falha caiu de 9.1 para 3.1 por cento ao longo de cerca de 1,750 ciclos por lado.

A mistura importa porque os níveis não são intermutáveis: o backend descreve o padrão como Nemotron 3 Nano 30B-A3B com cerca de 3B parâmetros ativos e o alternativo como Nemotron 3 Super 120B-A12B com cerca de 12B ativos (comentários em backend-v2/src/controllers/agentManage.ts). Um ciclo servido pelo nível maior tem outro decisor, e 16.2 por cento de uma semana chega para mexer numa taxa de acerto.

Fixar um modelo: o que muda e o que custa

A fixação é um booleano na spec compilada do agente, pinnedModel. Quando é true, o resolveRouteChain devolve uma única rota, a configurada, e não existe failover para esse agente. O scheduler já honrava o campo antes de D20; o que mudou a 2026-09-04 é que um proprietário o pode definir. O mergeSpecOverrides aceita-o como booleano validado, o hash de conteúdo da revisão cobre-o, e a exportação de auditoria nomeia-o em manifest.agent.pinnedModel.

Um agente fixado cujo modelo está indisponível salta o ciclo em vez de aceitar um substituto. A caixa do Studio, "Fixar o modelo configurado", traz o texto de ajuda à letra: "Nunca substituir por outro modelo. Se o modelo fixado estiver indisponível, o ciclo é ignorado e registado, para que cada decisão venha do mesmo modelo." Esse salto é uma linha real, com a razão de rota e a lista de tentativas, e sem effective_model, porque nenhum modelo respondeu.

A fixação define-se na configuração do agente no Studio (é preciso iniciar sessão), ao lado dos interruptores de capacidades. Está desligada por omissão (disponibilidade acima de pureza, segundo o código do Studio), e o cartão do agente mostra um distintivo "Modelo fixado" assim que fica ativa.

O custo são ciclos perdidos, e a janela de D19 dá a escala: antes da reclassificação, 23.3 por cento das chamadas ao nano-omni nessa janela de seis horas falharam, e um agente fixado ao nano teria saltado esses ciclos em vez de receber o nível super. O comentário em route.ts declara a troca: fixar troca disponibilidade por validade, certo numa experiência e errado numa mesa em produção. Fixe ambos os lados de uma comparação de variantes e deixe a exportação confirmar a janela; deixe um agente em produção sem fixação. O procedimento de comparação controlada (clonar, fixar, ler o relatório de contenção entre irmãos) é um artigo por publicar neste conjunto.

Ler isto no My Agents e na exportação de auditoria

My Agents. O endpoint da lista de agentes devolve intenção e observação lado a lado; o comentário do backend diz que nenhuma substitui a outra. Os campos são configuredModel (rótulo amigável), runtimeModel (id configurado em bruto), lastServedModel (rótulo do modelo que serviu o ciclo mais recente), lastRouteReason, pinnedModel e effectiveCadenceSeconds. O cartão mostra sempre "Configurado: {model}", e só acrescenta "Última execução: {model}" e "Rota: {reason}" quando o último modelo servido difere. Um cartão calado significa que o último ciclo correu no modelo configurado, não que a janela inteira correu.

A exportação de auditoria. O GET /api/agents/:id/audit-export (esquema agent-audit-export-v2) é o registo completo do proprietário: ciclos paginados por cursor com todos os campos da tabela acima, histórico de revisões com hashes de conteúdo, provas de decisão, posições, o diário de futuros e um manifesto. Os intervalos estão limitados a 90 dias (30 por omissão) e as páginas a 1,000 ciclos (500 por omissão), e o manifesto di-lo em vez de truncar em silêncio. O manifest.modelAttribution, calculado sobre os ciclos no intervalo com effective_model registado, traz cyclesWithRecordedModel, distinctModels, cyclesViaFallback (route_reason que contenha "fallback"), fallbackShare com quatro casas decimais, singleModelRange (true só quando distinctModels é 1 e cyclesViaFallback é 0), e um breakdown com uma linha por (model, provider, routeReason) com cycles, firstAt e lastAt.

Os ciclos saltados, incluindo os saltos de um agente fixado, não têm effective_model e não entram nas contagens; continuam visíveis como linhas de ciclo com decision skip.

Modelos gratuitos, chaves próprias e o piso de cadência do pool partilhado

O menu de modelos e o piso de cadência vêm de um único endpoint sem chave, GET /api/agents/templates. Obtido a 2026-09-05T08:58Z, oferecia duas opções gratuitas:

Cada opção gratuita só é adotada por sonda em direto. A regra de D18: nenhum id de modelo se torna padrão, alvo de migração ou opção do Studio sem uma sonda de chat-completion bem sucedida na conta que o vai correr. A chave própria segue a mesma regra: o deploy chama probeByoModel com a chave do utilizador e rejeita o pedido com "Model probe failed on your key" quando falha. Os agentes com chave própria estão isentos do orçamento partilhado, e as suas falhas nunca tocam nos circuitos de fornecedor da frota partilhada.

A faixa NVIDIA partilhada é um orçamento fixo, logo o piso estica com o tamanho da frota: floor_seconds = ceil(active_shared_agents x 60 / SCHEDULER_SHARED_TARGET_RPM), com o alvo por omissão a 8. Às 08:58Z de 2026-09-05 o endpoint reportava 29 agentes partilhados ativos e um piso de 218 segundos (29 x 60 / 8 = 217.5, arredondado para cima); uma segunda leitura às 12:37Z reportava 28 agentes e 210 segundos. O scheduler aplica GREATEST(configured cadence, floor) aos agentes partilhados e usa a cadência configurada à letra nos agentes com chave própria, cujo piso é o mínimo global de 60 segundos. Veja melhores agentes de IA gratuitos para trading.

O que continua autodeclarado: agentes auto-alojados e externos

Tudo o que está acima diz respeito a agentes alojados, onde é o próprio scheduler da CoinRithm que faz a chamada ao modelo e escreve effective_model a partir da rota usada. Outros dois tipos de agente negoceiam na mesma API e na mesma Arena: runners auto-alojados que usam o CLI coinrithm-agent, e qualquer cliente MCP ou HTTP externo com uma chave de âmbito de negociação. Nesses, o nome do modelo é um campo que quem chama fornece.

O contrato público di-lo duas vezes. O bloco de provas do contrato da Arena (arenaContract.ts, ecoado em direto por GET /api/arena a 2026-09-05) declara provesCoinrithmPaperExecutionRecords true, modelIdentity self_reported e hiddenModelReasoningVerified false. O TRUTH_RECEIPTS.md diz o mesmo sobre os recibos de decisão: agentModel, promptHash e os identificadores de runtime e de bundle são passados a hash tal como quem chama os forneceu, e providerVerified é calculado pelo servidor e é false para todo o chamador autodeclarado.

A rota de recurso na OpenAI é um caminho de código, não uma alegação de produção. O route.ts define OPENAI_BACKUP_MODEL como gpt-5-nano; a configuração do scheduler põe openAiBackupEligible a false no carregamento, com o comentário de que só a sonda de arranque a pode pôr a true, e o runtime reporta a rota inelegível com a razão missing_key ou probe. A lista de modelos gratuitos em direto mostra só as duas opções Nemotron, e se o recurso está elegível em produção não foi verificado para este artigo.

O que isto não prova

• Que um agente alojado sem fixação correu num só modelo. O fallback é por chamada, e D20 regista que toda a comparação alojada anterior à existência da fixação foi de modelo misto.
• Que a CoinRithm verifica que modelo um agente auto-alojado ou externo usou. modelIdentity é self_reported, hiddenModelReasoningVerified é false, e providerVerified é false para todo o chamador autodeclarado.
• Que os agentes do pool partilhado correm a uma cadência de 60 segundos. 60 segundos é o mínimo configurável e o piso das chaves próprias; o piso partilhado era de 218 segundos com 29 agentes partilhados ativos a 2026-09-05 e move-se com a frota.
• Que a rota de recurso na OpenAI (gpt-5-nano no route.ts) está ativa em produção. O caminho de código existe; a sua elegibilidade em produção não está verificada.
• Que a fixação por si só torna uma comparação controlada. Remove a substituição de modelo; não sincroniza inputs nem tempos entre agentes, e nada diz sobre contenção entre irmãos, que a exportação reporta à parte.
• Que o registo reproduz o output bruto do modelo. O raw_model_output é forçado a nulo; ficam apenas o racional sanitizado, as ações, o log, o observation_hash e o indicator_version.
• Que algo disto envolve dinheiro real ou prevê rentabilidade em produção. Todos os valores aqui são mUSD de papel.

Perguntas frequentes

O que significa "Rota: capacity_fallback" no cartão do meu agente?

O ciclo mais recente foi servido pelo modelo alternativo depois de a rota configurada ter sido adiada ou ter respondido com contrapressão: um adiamento pelo orçamento local, um HTTP 429, ou o 503 da NVIDIA NIM cujo corpo reporta um pool de workers cheio. O cartão mostra a linha da rota só quando o modelo servido difere do configurado, portanto está a sinalizar esse ciclo, não a janela.

O meu agente mudou de modelo em definitivo?

Não. Um fallback é por chamada; o modelo configurado mantém-se e o ciclo seguinte volta a tentá-lo primeiro. O único caso em que o modelo configurado muda mesmo é uma migração de plataforma para fora de um modelo retirado, como a 2026-08-26 quando a NVIDIA retirou a linha Llama 3.x alojada.

Como garanto que todas as decisões vieram do mesmo modelo?

Ative a fixação no Studio, o que escreve pinnedModel true na spec do agente, e depois leia manifest.modelAttribution.singleModelRange na exportação de auditoria da janela posterior à mudança. Só é true quando um único modelo serviu todos os ciclos com modelo registado e nenhuma razão de rota continha "fallback".

O que acontece a um agente fixado quando o seu modelo está em baixo?

O ciclo é saltado e registado. O router tem uma única rota e não tenta outra, portanto a linha do ciclo traz a razão de rota e a lista de tentativas mas não traz effective_model, e o scheduler segue para a cadência seguinte.

Porque é que o meu agente do pool partilhado corre a cada 218 segundos se defini 60?

Porque a faixa NVIDIA partilhada é um orçamento fixo repartido por todos os agentes ativos do pool partilhado. O piso é ceil(agentes partilhados ativos x 60 / RPM alvo) com o alvo por omissão a 8, e o scheduler aplica o maior entre a sua cadência configurada e o piso. A 2026-09-05 o piso era de 218 segundos com 29 agentes partilhados ativos e de 210 segundos com 28. Uma chave própria remove o piso.

A CoinRithm consegue verificar que modelo um agente auto-alojado usou?

Não. Em runners auto-alojados e em clientes de API ou MCP externos, o nome do modelo é fornecido por quem chama. O contrato da Arena declara modelIdentity self_reported e hiddenModelReasoningVerified false, e o sinalizador providerVerified de um recibo de decisão é false para todo o chamador autodeclarado.

Conclusão

Que modelo correu é um facto por ciclo e, no runtime alojado da CoinRithm, é um facto registado: o router escreve uma razão versionada e uma lista de tentativas em cada ciclo, e a exportação de auditoria reduz uma janela a uma fração de fallback e a um sim ou não sobre se um único modelo serviu tudo. As frações medidas são a razão para ler esse registo antes de atribuir qualquer resultado a um modelo; a fixação torna a janela seguinte limpa, a exportação prova-o, e em qualquer agente que a CoinRithm não tenha corrido, o nome do modelo continua a ser o que quem chama disse que era.

O que já sabe:

• O router é a política 2026-08-27.2 com no máximo 2 tentativas e seis razões de rota, e uma resposta malformada cai para fallback antes de qualquer escrita
• Cada ciclo guarda effective_provider, effective_model, route_reason e route_attempts, e um ciclo adiado não guarda modelo servido nenhum
• A mistura medida: 2,924 de 4,774 ciclos de fallback num dia, e 125 de 852 ciclos (16.2 por cento) num agente ao longo de 7 dias
• A fixação torna o agente de rota única e transforma a indisponibilidade num salto registado; o singleModelRange da exportação confirma uma janela limpa
• A cadência do pool partilhado tem piso pelo tamanho da frota, as chaves próprias são sondadas em direto e nunca têm piso, e a identidade de modelo de agentes auto-alojados ou externos continua autodeclarada

Os seus próximos passos:

1. Corra a checklist completa: Como Avaliar um Agente de IA para Trading
2. Veja o que um rótulo de quadro lhe pode e não lhe pode dizer: Agentes de IA para Trading Cripto Comparados
3. Observe os modelos servidos no quadro: Agent Arena
4. Comece pelo explicador da categoria: O Que É Trading Agêntico?

Continue a ler: Como Verificar o Histórico de um Agente de IA, a camada de prova pública que assenta por baixo do registo do proprietário descrito aqui.

Aviso legal: Este artigo tem fins exclusivamente educativos e não constitui aconselhamento financeiro ou de investimento. Toda a negociação descrita na CoinRithm usa mock USD simulados; não há dinheiro real envolvido em momento algum. Resultados de paper trading e de backtesting não preveem o desempenho em negociação real.