Il tuo agente chiude la settimana con una curva di equity ordinata, e la sua scheda dice Nemotron 3 Nano 30B. Apri il run e scopri che circa un ciclo su sei ha ricevuto risposta da un modello quattro volte più grande. Nessuno ha mentito: la scheda mostra il modello che l'agente è configurato per usare. La domanda giusta è più circoscritta: quale modello ha davvero risposto a ogni ciclo, e il record lo dice in una forma che puoi controllare?
L'attribuzione del modello per un agente di trading è il record, ciclo per ciclo, di quale modello e quale provider hanno prodotto ogni decisione, tenuto separato dal modello che l'agente era configurato per usare. Il runtime agentico hosted di CoinRithm instrada gli agenti sul pool condiviso attraverso un router versionato che può servire un sostituto quando il modello configurato è saturo, ritirato o restituisce output non interpretabile, e scrive l'esito di ogni ciclo nel record dell'agente.
Per la checklist completa in nove domande, leggi Come Valutare un Agente AI di Trading, l'hub di questo articolo. Per i backend confrontati sulla classifica pubblica, leggi Confronto Agenti AI di Trading Crypto. Per hash e ricevute, leggi Come Verificare lo Storico di un Agente IA.
Verità di base prima di proseguire: ogni affermazione su CoinRithm in questo articolo descrive un ambiente di paper trading. Gli agenti su CoinRithm operano in mUSD virtuali contro prezzi di mercato live, mai con denaro reale. Nulla qui è consulenza finanziaria e nulla promette che un agente, su CoinRithm o altrove, guadagnerà. Sul capitale, il contratto Arena pubblicato (arena-ranking-v1, letto senza chiave da GET /api/arena il 2026-09-05) dichiara che dal 2026-09-05 ogni API key, cioè ogni agente, opera sul proprio book di carta finanziato con 50,000 mUSD al primo utilizzo (executionWalletScope api_key, independentWalletPerAgent true, independentWalletSince 2026-09-05); i risultati precedenti provengono da un unico wallet di account e negli export di audit sono etichettati shared-capital.
TL;DR
- Se l'agente non aveva il pin, tratta un risultato hosted su pool condiviso come multi-modello. Nelle 24 ore fino al 2026-09-04, 2,924 delle 4,774 chiamate al modello in produzione sono state cicli di fallback, e nessun agente in produzione aveva il pin (DECISIONS.md D20).
- Il router è versionato e limitato: policy 2026-08-27.2, al massimo 2 tentativi di routing per ciclo, sei motivi di routing registrati.
- Ogni ciclo persiste effective_provider, effective_model, route_reason e route_attempts, accanto a observation_hash, indicator_version e ai conteggi di token.
- L'export di audit risponde direttamente: manifest.modelAttribution riporta un fallbackShare e un flag singleModelRange che è true solo quando un unico modello ha servito ogni ciclo senza failover.
- Il pin scambia disponibilità con validità. Dal 2026-09-04 una casella in Studio imposta pinnedModel; un agente con il pin viene instradato solo al modello configurato e salta il ciclo, registrandolo, quando quel modello non è disponibile. Gli agenti self-host ed esterni restano autodichiarati.
La risposta breve: se non hai messo il pin, i risultati sono un mix, e il record dice quanto
Un agente hosted sul pool di modelli condiviso di CoinRithm non gira su un solo modello. Gira su una catena di route: prima il modello configurato, poi un'alternativa sondata dal vivo quando la prima route è satura, interrotta o non interpretabile. Due fatti datati fissano il default. Il router è versionato (policy 2026-08-27.2 in packages/scheduler/src/route.ts) e prova al massimo 2 route per ciclo. E nelle 24 ore fino al 2026-09-04, 2,924 delle 4,774 chiamate al modello in produzione sono state cicli di fallback, circa il 61 per cento, mentre zero agenti in produzione avevano il pin impostato (DECISIONS.md D20).
Quindi il prior onesto per qualunque risultato hosted registrato prima che tu mettessi il pin è: misto. Ogni ciclo salva il modello che ha risposto e il motivo per cui il router lo ha scelto, e l'export di audit del proprietario riduce una finestra a un solo verdetto, singleModelRange. La procedura:
- Apri la scheda dell'agente in My Agents. Mostra il modello configurato e, solo quando l'ultimo ciclo è stato servito da un modello diverso, aggiunge "Ultima esecuzione: {model}" e "Percorso: {reason}".
- Scarica l'export di audit per la finestra. Leggi manifest.agent.pinnedModel, poi manifest.modelAttribution.
- Se singleModelRange è false, separa l'analisi per le righe di breakdown prima di concludere qualunque cosa sul modello.
- Se ti serve un run pulito, imposta il pin, rimetti online l'agente e conferma che la finestra successiva torni singleModelRange true.
Come funziona il router: una versione di policy, due tentativi, sei motivi di routing
Il router vive nello scheduler hosted (packages/scheduler/src/route.ts) ed è identificato da ROUTE_POLICY_VERSION, attualmente "2026-08-27.2", scritta nei metadati di route di ogni ciclo, così un cambio di regole è visibile nel record. MAX_ROUTE_ATTEMPTS è 2. resolveRouteChain costruisce la catena a partire dal modello configurato: i due tier Nemotron gratuiti sono l'alternativa l'uno dell'altro, quindi un agente sul tier veloce (NEMOTRON_NANO, id nvidia/nemotron-3-nano-omni-30b-a3b-reasoning) riceve il tier potente (NEMOTRON_SUPER, id nvidia/nemotron-3-super-120b-a12b) come seconda route e viceversa, mentre un modello configurato fuori da questi due non riceve alcuna alternativa Nemotron. Una route di backup OpenAI (OPENAI_BACKUP_MODEL è gpt-5-nano) viene aggiunta solo quando il flag openAiBackup dello scheduler è true. Due casi riducono la catena a una sola route: una chiave personale e il pin.
I fallimenti sono classificati in base a cosa ha risposto il provider, in capacity, permanent, transient e malformed: un HTTP 429 è capacity; anche un 503 il cui corpo contiene ResourceExhausted o "worker local total request limit" è capacity, perché NVIDIA NIM usa quel corpo per un pool di worker per modello saturo (DECISIONS.md D19); 404 e 410 sono permanent; tutto il resto è transient. Capacity blocca solo la route satura; transient blocca l'intero provider quando ne resta uno indipendente; permanent colpisce il circuito della flotta. Il ciclo si chiude con uno di sei motivi:
| Motivo di routing | Quando il router lo scrive | Cosa dice sul modello servito |
|---|---|---|
| configured | La prima route ha risposto e il suo testo ha superato il parser delle decisioni | Ha servito il modello configurato |
| byo | L'agente gira su una chiave personale, quindi la catena è una sola route | Ha servito il modello configurato, sulla quota dell'utente |
| circuit_fallback | La route configurata è stata saltata prima di ogni chiamata perché il suo circuito era aperto | Ha servito un sostituto, o nessuno se l'agente ha il pin |
| capacity_fallback | La route configurata è stata rinviata dal budget locale, ha risposto 429 o ha restituito il 503 NIM ResourceExhausted | Ha servito un sostituto dopo backpressure |
| provider_fallback | La route configurata è fallita con un errore transient (5xx, trasporto) o permanent (404, 410) | Ha servito un sostituto dopo un guasto reale del provider |
| malformed_fallback | Il modello configurato ha risposto, ma il testo non ha superato il parser delle decisioni | Ha servito un sostituto dopo output non interpretabile |
Cosa viene registrato a ogni ciclo
Il router restituisce i metadati di route con ogni decisione, riuscita o no, e il runtime dello scheduler (packages/scheduler/src/runtime.ts) li persiste con il resto del ciclo in agent_runtime.agent_cycles:
| Campo | Contenuto | Note |
|---|---|---|
| effective_model, effective_provider | Il modello e il provider il cui testo è stato accettato | Null quando non è stata fatta alcuna chiamata |
| route_reason | Uno dei sei valori qui sopra | Scritto anche quando il ciclo è stato saltato |
| route_attempts | Per tentativo: provider, modello, esito (success, failed, deferred), failureClass, stato HTTP, retryAfterMs, latencyMs, errore sanificato | Token Bearer mascherati, errori tagliati a 200 caratteri |
| observation_hash, indicator_version | Impronta e versione di ciò che il modello ha visto | Il payload in sé non viene conservato |
| llm_call_made, tokens_in, tokens_out, estimated_cost_usd | Misurazione | tokens_in è 0 quando il ciclo è stato rinviato senza chiamata |
| decision, skip_reason, model_failed, decision_type | Cosa ha fatto il ciclo | Un rinvio per capacity è decision skip, model_failed false |
Due regole del runner (packages/mcp-trading/src/agent/runner.ts) tengono onesti i bordi. Se ogni tentativo è stato rinviato, nessuna chiamata è avvenuta: effective_model resta vuoto, llm_call_made è false, tokens_in è 0 e il ciclo è uno skip con motivo "capacità del provider rinviata". Se una chiamata ha raggiunto il provider ma ogni tentativo è fallito per capacity, il ciclo riporta "provider con rate limit; riprova al ciclo successivo" con model_failed false, così la pressione sulla quota non conta mai come prova che il modello sia rotto.
Quanto è grande il mix, con le date
Su tutta la flotta, 24 ore fino al 2026-09-04. 2,924 delle 4,774 chiamate al modello sono state cicli di fallback, e zero agenti in produzione avevano pinnedModel impostato, perché fino a D20 nulla poteva impostarlo. D20 trae la conclusione: ogni confronto hosted fino a quel punto è stato un confronto multi-modello, qualunque etichetta portasse.
Un agente, 7 giorni. 852 cicli: 587 sul modello configurato poi ritirato, circa 136 su quello attuale e 125 (16.2 per cento) serviti da un modello più grande attraverso fallback di circuito, provider, capacity e malformed (commenti in auditExport.ts e route.ts). Questo mostra entrambi i modi in cui una finestra diventa mista. Il modello configurato è cambiato a metà finestra, perché NVIDIA ha ritirato la linea Llama 3.x hosted con 410 Gone alle 2026-08-26T09:00Z e la migrazione al boot dello scheduler ha rimappato 37 agenti e ne ha risvegliati 23 disattivati (DECISIONS.md D18). Inoltre il router ha fatto failover chiamata per chiamata.
Capacity contro guasto, 6 ore il 2026-09-03. Su 1,288 chiamate instradate, 169 sono state registrate come model_failed e 142 di queste (84 per cento) portavano il corpo NIM ResourceExhausted; nano-omni-30b ha fallito 136 chiamate su 583 (23.3 per cento) contro le 33 su 705 di super-120b (4.7 per cento). Dopo la riclassificazione D19 il tasso di fallimento è sceso da 9.1 a 3.1 per cento su circa 1,750 cicli per lato.
Il mix conta perché i tier non sono intercambiabili: il backend descrive il default come Nemotron 3 Nano 30B-A3B con circa 3B parametri attivi e l'alternativa come Nemotron 3 Super 120B-A12B con circa 12B attivi (commenti in backend-v2/src/controllers/agentManage.ts). Un ciclo servito dal tier più grande è un decisore diverso, e il 16.2 per cento di una settimana basta a muovere un win rate.
Mettere il pin a un modello: cosa cambia e quanto costa
Il pin è un booleano nella spec compilata dell'agente, pinnedModel. Quando è true, resolveRouteChain restituisce una sola route, quella configurata, e per quell'agente il failover non esiste. Lo scheduler onorava il campo già prima di D20; ciò che è cambiato il 2026-09-04 è che un proprietario può impostarlo. mergeSpecOverrides lo accetta come booleano validato, l'hash del contenuto della revisione lo copre e l'export di audit lo riporta in manifest.agent.pinnedModel.
Un agente con il pin il cui modello non è disponibile salta il ciclo invece di prendere un sostituto. La casella in Studio, "Blocca il modello configurato", porta il testo di aiuto alla lettera: "Non sostituire mai con un altro modello. Se il modello bloccato non è disponibile, il ciclo viene saltato e registrato, così ogni decisione proviene dallo stesso modello." Quello skip è una riga reale, con motivo di routing e lista dei tentativi ma senza effective_model, perché nessun modello ha risposto.
Il pin si imposta nella configurazione dell'agente in Studio (serve l'accesso), accanto agli interruttori delle capability. È disattivo di default (disponibilità prima della purezza, secondo il sorgente di Studio) e la scheda dell'agente mostra un badge "Modello bloccato" quando è attivo.
Il costo sono i cicli persi, e la finestra D19 ne dà la scala: prima della riclassificazione, in quelle sei ore è fallito il 23.3 per cento delle chiamate a nano-omni, e un agente con il pin su nano avrebbe saltato quei cicli invece di ricevere il tier super. Il commento in route.ts dichiara lo scambio: il pin baratta disponibilità con validità, lo scambio corretto per un esperimento e sbagliato per un desk operativo. Metti il pin a entrambi i lati di un confronto tra varianti e lascia che l'export confermi la finestra; lascia senza pin un agente che opera davvero. La procedura di confronto controllato (clonare, mettere il pin, leggere il rapporto sulla contesa tra fratelli nell'export) è un articolo in arrivo di questo cluster.
Leggerlo in My Agents e nell'export di audit
My Agents. L'endpoint della lista agenti restituisce intenzione e osservazione affiancate; il commento nel backend dice che nessuna sostituisce l'altra. I campi sono configuredModel (etichetta leggibile), runtimeModel (id configurato grezzo), lastServedModel (etichetta leggibile del modello che ha servito il ciclo più recente), lastRouteReason, pinnedModel ed effectiveCadenceSeconds. La scheda mostra sempre "Configurato: {model}" e aggiunge "Ultima esecuzione: {model}" e "Percorso: {reason}" solo quando l'ultimo modello servito è diverso. Una scheda silenziosa significa che l'ultimo ciclo è girato sul modello configurato, non che ci sia girata l'intera finestra.
L'export di audit. GET /api/agents/:id/audit-export (schema agent-audit-export-v2) è il record completo del proprietario: cicli paginati a cursore con ogni campo della tabella qui sopra, storico delle revisioni con hash del contenuto, evidenze delle decisioni, posizioni, giornale futures e un manifest. Gli intervalli sono limitati a 90 giorni (30 di default) e le pagine a 1,000 cicli (500 di default), e il manifest lo dichiara invece di troncare in silenzio. manifest.modelAttribution, calcolato sui cicli in intervallo con un effective_model registrato, porta cyclesWithRecordedModel, distinctModels, cyclesViaFallback (route_reason che contiene "fallback"), fallbackShare a quattro decimali, singleModelRange (true solo quando distinctModels è 1 e cyclesViaFallback è 0) e un breakdown con una riga per (model, provider, routeReason) con cycles, firstAt e lastAt.
I cicli saltati, compresi quelli di un agente con il pin, non hanno effective_model e non entrano nei conteggi; restano visibili come righe di ciclo con decision skip.
Modelli gratuiti, chiavi BYO e la soglia minima di cadenza del pool condiviso
Il menu dei modelli e la soglia minima di cadenza vengono da un unico endpoint senza chiave, GET /api/agents/templates. Letto alle 2026-09-05T08:58Z offriva due opzioni gratuite:
| Opzione | Id servito | Tag di velocità | Cadenza minima | Catena di route senza pin |
|---|---|---|---|---|
| Nemotron 3 Nano 30B (default) | default (il modello del template, invariato) | fast | 60 s | Prima il tier veloce, Super 120B come alternativa |
| Nemotron 3 Super 120B | nvidia/nemotron-3-super-120b-a12b | balanced | 60 s | Prima il tier potente, Nano come alternativa |
| Chiave personale (BYO) | Qualsiasi modello che superi una sonda dal vivo sulla tua chiave | none | 60 s, mai soggetta alla soglia minima di flotta | Route singola, motivo byo |
Ogni opzione gratuita è adottata solo per sonda dal vivo. La regola di D18: nessun id di modello diventa un default, un bersaglio di migrazione o un'opzione di Studio senza una sonda di chat-completion riuscita sull'account che lo eseguirà. L'accettazione BYO usa la stessa regola: il deploy chiama probeByoModel con la chiave dell'utente e altrimenti rifiuta la richiesta con "La sonda del modello è fallita sulla tua chiave". Gli agenti BYO sono esenti dal budget condiviso e i loro fallimenti non toccano mai i circuiti del provider della flotta condivisa.
La corsia NVIDIA condivisa è un budget fisso, quindi la soglia minima si allunga con la dimensione della flotta: floor_seconds = ceil(active_shared_agents x 60 / SCHEDULER_SHARED_TARGET_RPM), con target di default 8. Alle 08:58Z del 2026-09-05 l'endpoint riportava 29 agenti condivisi attivi e una soglia minima di 218 secondi (29 x 60 / 8 = 217.5, arrotondato per eccesso); una seconda lettura alle 12:37Z riportava 28 agenti e 210 secondi. Lo scheduler applica GREATEST(cadenza configurata, soglia minima) agli agenti condivisi e usa la cadenza configurata alla lettera per gli agenti BYO, la cui soglia minima è il minimo globale di 60 secondi. Vedi i migliori agenti AI di trading gratuiti.
Cosa resta autodichiarato: agenti self-host ed esterni
Tutto quanto sopra riguarda gli agenti hosted, dove lo scheduler di CoinRithm fa la chiamata al modello e scrive effective_model dalla route usata. Altri due tipi di agente operano sulla stessa API e sulla stessa Arena: i runner self-host che usano la CLI coinrithm-agent e qualunque client MCP o HTTP esterno con una chiave abilitata al trading. Per quelli, il nome del modello è un campo che fornisce il chiamante.
Il contratto pubblico lo dice due volte. Il blocco evidenze del contratto Arena (arenaContract.ts, restituito dal vivo da GET /api/arena il 2026-09-05) dichiara provesCoinrithmPaperExecutionRecords true, modelIdentity self_reported e hiddenModelReasoningVerified false. TRUTH_RECEIPTS.md dice lo stesso sulle ricevute di decisione: agentModel, promptHash e gli identificatori di runtime e bundle sono sottoposti ad hash come forniti dal chiamante, e providerVerified è calcolato dal server ed è false per ogni chiamante autodichiarato.
La route di backup OpenAI è un percorso di codice, non un'affermazione di produzione. route.ts definisce OPENAI_BACKUP_MODEL come gpt-5-nano; la configurazione dello scheduler imposta openAiBackupEligible a false al caricamento, con il commento che solo la sonda di avvio può portarlo a true, e altrimenti il runtime riporta la route non eleggibile con motivo missing_key o probe. La lista live dei modelli gratuiti mostra solo le due opzioni Nemotron, e se il backup sia eleggibile in produzione non è stato verificato per questo articolo.
Cosa questo non dimostra
- Che un agente hosted senza pin sia girato su un solo modello. Il fallback è per chiamata, e D20 registra che ogni confronto hosted precedente all'esistenza del pin era un confronto multi-modello.
- Che CoinRithm verifichi quale modello ha usato un agente self-host o esterno. modelIdentity è self_reported, hiddenModelReasoningVerified è false e providerVerified è false per ogni chiamante autodichiarato.
- Che gli agenti su pool condiviso girino con cadenza di 60 secondi. 60 secondi è il minimo configurabile ed è la soglia minima BYO; la soglia minima condivisa era 218 secondi con 29 agenti condivisi attivi il 2026-09-05 e si muove con la flotta.
- Che la route di backup OpenAI (gpt-5-nano in route.ts) sia attiva in produzione. Il percorso di codice esiste; la sua eleggibilità in produzione non è verificata.
- Che il pin da solo renda controllato un confronto. Rimuove la sostituzione del modello; non sincronizza input né tempi tra agenti, e non dice nulla sulla contesa tra fratelli, che l'export riporta a parte.
- Che il record riproduca l'output grezzo del modello. raw_model_output è forzato a null; restano solo il razionale sanificato, le azioni, il log, observation_hash e indicator_version.
- Che qualcosa di tutto ciò coinvolga denaro reale o predica la redditività dal vivo. Ogni cifra qui è mUSD di carta.
Domande frequenti
Cosa significa "Percorso: capacity_fallback" sulla scheda del mio agente?
Che il ciclo più recente è stato servito dal modello alternativo dopo che la route configurata era stata rinviata o aveva risposto con backpressure: un rinvio del budget locale, un HTTP 429 o il 503 di NVIDIA NIM il cui corpo segnala un pool di worker saturo. La scheda mostra la riga di route solo quando il modello servito è diverso da quello configurato, quindi segnala quel ciclo, non la finestra.
Il mio agente ha cambiato modello in modo permanente?
No. Un fallback vale per chiamata; il modello configurato resta invariato e il ciclo successivo lo prova di nuovo per primo. L'unico caso in cui il modello configurato cambia davvero è una migrazione di piattaforma via da un modello ritirato, come il 2026-08-26 quando NVIDIA ha ritirato la linea Llama 3.x hosted.
Come faccio a essere sicuro che ogni decisione venga dallo stesso modello?
Imposta il pin in Studio, che scrive pinnedModel true nella spec dell'agente, poi leggi manifest.modelAttribution.singleModelRange nell'export di audit per la finestra successiva al cambio. È true solo quando un unico modello ha servito ogni ciclo con un modello registrato e nessun motivo di routing conteneva "fallback".
Cosa succede a un agente con il pin quando il suo modello non è disponibile?
Il ciclo viene saltato e registrato. Il router ha una sola route e non ne prova altre, quindi la riga di ciclo porta il motivo di routing e la lista dei tentativi ma nessun effective_model, e lo scheduler passa alla cadenza successiva.
Perché il mio agente su pool condiviso gira ogni 218 secondi se ho impostato 60?
Perché la corsia NVIDIA condivisa è un budget fisso diviso tra tutti gli agenti attivi sul pool condiviso. La soglia minima è ceil(agenti condivisi attivi x 60 / target RPM) con il target di default a 8, e lo scheduler applica il maggiore tra la tua cadenza configurata e la soglia minima. Il 2026-09-05 la soglia minima era 218 secondi con 29 agenti condivisi attivi e 210 secondi con 28. Una chiave personale rimuove la soglia minima.
CoinRithm può verificare quale modello ha usato un agente self-hosted?
No. Per i runner self-host e per i client API o MCP esterni, il nome del modello lo fornisce il chiamante. Il contratto Arena dichiara modelIdentity self_reported e hiddenModelReasoningVerified false, e il flag providerVerified di una ricevuta di decisione è false per ogni chiamante autodichiarato.
Conclusione
Quale modello ha girato è un fatto per ciclo, e sul runtime hosted di CoinRithm è un fatto registrato: il router scrive un motivo versionato e una lista di tentativi in ogni ciclo, e l'export di audit riduce una finestra a una quota di fallback e a un solo sì o no sul fatto che un unico modello l'abbia servita tutta. Le quote misurate sono la ragione per leggere quel record prima di attribuire qualunque risultato a un modello; il pin rende pulita la finestra successiva, l'export lo dimostra, e per ogni agente che CoinRithm non ha eseguito in proprio il nome del modello resta ciò che ha dichiarato il chiamante.
Cosa sai ora:
- Il router è la policy 2026-08-27.2 con al massimo 2 tentativi e sei motivi di routing, e una risposta non interpretabile va in fallback prima di ogni scrittura
- Ogni ciclo salva effective_provider, effective_model, route_reason e route_attempts, e un ciclo rinviato non salva alcun modello servito
- Il mix misurato: 2,924 cicli di fallback su 4,774 in un giorno, e 125 cicli su 852 (16.2 per cento) per un agente in 7 giorni
- Il pin rende l'agente a route singola e trasforma l'indisponibilità in uno skip registrato; singleModelRange nell'export conferma una finestra pulita
- La cadenza sul pool condiviso ha una soglia minima legata alla dimensione della flotta, le chiavi BYO sono sondate dal vivo e mai soggette alla soglia minima, e l'identità del modello di self-host ed esterni resta autodichiarata
I prossimi passi:
- Esegui la checklist completa: Come Valutare un Agente AI di Trading
- Guarda cosa può e non può dirti l'etichetta di una classifica: Confronto Agenti AI di Trading Crypto
- Osserva i modelli serviti sulla classifica: Agent Arena
- Parti dalla spiegazione di categoria: Cos'è il Trading Agentico?
Continua a leggere: Come Verificare lo Storico di un Agente IA, il livello di prova pubblica che sta sotto il record del proprietario descritto qui.
Disclaimer: Questo articolo ha finalità esclusivamente didattiche e non costituisce consulenza finanziaria o di investimento. Tutto il trading descritto su CoinRithm usa mock USD simulati; in nessun momento è coinvolto denaro reale. I risultati di paper trading e backtest non predicono la performance del trading reale.
