Welk model gebruikte je AI-tradingagent echt? Routing, fallbacks en vastpinnen, cyclus voor cyclus

Je agent sluit de week af met een nette equity curve, en op zijn kaart staat Nemotron 3 Nano 30B. Je haalt de run op en ontdekt dat ongeveer één cyclus op zes is beantwoord door een model dat vier keer zo groot is. Niemand heeft gelogen: de kaart toont waarvoor de agent is geconfigureerd. De juiste vraag is scherper: welk model heeft elke cyclus daadwerkelijk beantwoord, en zegt de registratie dat in een vorm die je kunt narekenen?

Modelattributie voor een tradingagent is de registratie per cyclus van welk model en welke provider elke beslissing produceerde, apart bijgehouden van het model waarvoor de agent was geconfigureerd. De gehoste runtime voor agentisch traden van CoinRithm stuurt agents op de gedeelde pool door een geversioneerde router die een vervanger kan inzetten wanneer het geconfigureerde model verzadigd is, is uitgefaseerd of onleesbare output teruggeeft, en schrijft de uitkomst van elke cyclus naar de registratie van de agent.

Voor de volledige checklist van negen vragen lees je Hoe beoordeel je een AI-tradingagent, de hub van dit artikel. Voor backends die op het publieke leaderboard worden vergeleken, lees je AI-crypto-tradingagents vergeleken. Voor hashes en bewijzen lees je Hoe je het trackrecord van een AI-agent verifieert.

Uitgangspunt voordat je verder leest: elke bewering over CoinRithm in dit artikel beschrijft een paper-trading-omgeving. Agents op CoinRithm handelen met virtuele mUSD tegen live marktprijzen, nooit met echt geld. Niets hiervan is financieel advies, en niets hiervan belooft dat een agent, op CoinRithm of waar dan ook, geld zal verdienen. Over kapitaal stelt het gepubliceerde Arena-contract (arena-ranking-v1, zonder sleutel opgehaald bij GET /api/arena op 2026-09-05) dat sinds 2026-09-05 elke API-sleutel, dus elke agent, handelt op een eigen paper-boek dat bij het eerste gebruik met 50,000 mUSD wordt gevuld (executionWalletScope api_key, independentWalletPerAgent true, independentWalletSince 2026-09-05); resultaten van vóór die datum kwamen uit één gedeelde accountwallet en worden in audit-exports gelabeld als shared-capital.

TL;DR

• Tenzij de agent was vastgepind, behandel je een gehost resultaat uit de gedeelde pool als gemengd model. In de 24 uur tot 2026-09-04 waren 2,924 van de 4,774 modelaanroepen op productie fallback-cycli, en was geen enkele productieagent vastgepind (DECISIONS.md D20).
• De router is geversioneerd en begrensd: policy 2026-08-27.2, maximaal 2 routepogingen per cyclus, zes vastgelegde routeredenen.
• Elke cyclus legt effective_provider, effective_model, route_reason en route_attempts vast, naast observation_hash, indicator_version en tokentellingen.
• De audit-export geeft direct antwoord: manifest.modelAttribution rapporteert een fallbackShare en een vlag singleModelRange die alleen true is wanneer één model elke cyclus bediende zonder enige failover.
• Vastpinnen ruilt beschikbaarheid in voor validiteit. Sinds 2026-09-04 zet een vinkje in Studio pinnedModel; een vastgepinde agent wordt uitsluitend naar zijn geconfigureerde model gerouteerd en slaat de cyclus over, met registratie, wanneer dat model niet beschikbaar is. Self-host en externe agents blijven zelf gerapporteerd.

Het korte antwoord: tenzij je hem hebt vastgepind, zijn de resultaten een mengeling, en de registratie zegt hoeveel

Een gehoste agent op de gedeelde modelpool van CoinRithm draait niet op één model. Hij draait op een routeketen: eerst zijn geconfigureerde model, dan een live geprobeerd alternatief zodra de eerste route verzadigd, uitgeschakeld of onleesbaar is. Twee gedateerde feiten bepalen de standaard. De router is geversioneerd (policy 2026-08-27.2 in packages/scheduler/src/route.ts) en probeert maximaal 2 routes per cyclus. En in de 24 uur tot 2026-09-04 waren 2,924 van de 4,774 modelaanroepen op productie fallback-cycli, ongeveer 61 procent, terwijl nul productieagents de pin hadden staan (DECISIONS.md D20).

De eerlijke aanname voor elk gehost resultaat dat is vastgelegd voordat jij de agent vastpinde, luidt dus: gemengd. Elke cyclus slaat op welk model antwoordde en waarom de router dat koos, en de audit-export van de eigenaar brengt een heel venster terug tot één oordeel, singleModelRange. De procedure:

1. Open de agentkaart in My Agents. Die toont het geconfigureerde model, en alleen wanneer een ander model de laatste cyclus bediende voegt hij "Laatste run: {model}" en "Route: {reason}" toe.
2. Haal de audit-export voor het venster op. Lees manifest.agent.pinnedModel, daarna manifest.modelAttribution.
3. Is singleModelRange false, splits je analyse dan langs de breakdown-rijen voordat je iets over het model concludeert.
4. Heb je een schone run nodig, zet dan de pin, rol opnieuw uit, en bevestig dat het volgende venster terugkomt met singleModelRange true.

Hoe de router werkt: één policyversie, twee pogingen, zes routeredenen

De router zit in de gehoste scheduler (packages/scheduler/src/route.ts) en wordt geïdentificeerd door ROUTE_POLICY_VERSION, op dit moment "2026-08-27.2", die in de routemetadata van elke cyclus wordt geschreven zodat een regelwijziging zichtbaar is in de registratie. MAX_ROUTE_ATTEMPTS is 2. resolveRouteChain bouwt de keten vanuit het geconfigureerde model: de twee gratis Nemotron-tiers zijn elkaars alternatief, dus een agent op de snelle tier (NEMOTRON_NANO, id nvidia/nemotron-3-nano-omni-30b-a3b-reasoning) krijgt de sterke tier (NEMOTRON_SUPER, id nvidia/nemotron-3-super-120b-a12b) als tweede route en omgekeerd, terwijl een geconfigureerd model buiten die twee geen Nemotron-alternatief krijgt. Een OpenAI-backuproute (OPENAI_BACKUP_MODEL is gpt-5-nano) wordt alleen toegevoegd wanneer de vlag openAiBackup van de scheduler true is. Twee gevallen laten de keten inklappen tot één route: een eigen sleutel en de pin.

Fouten worden geclassificeerd naar wat de provider zei, in capacity, permanent, transient en malformed: een HTTP 429 is capacity; een 503 waarvan de body overeenkomt met ResourceExhausted of "worker local total request limit" is eveneens capacity, omdat NVIDIA NIM die body gebruikt voor een volle workerpool per model (DECISIONS.md D19); 404 en 410 zijn permanent; al het overige is transient. Capacity blokkeert alleen de verzadigde route; transient blokkeert de hele provider zolang er een onafhankelijke overblijft; permanent raakt het vlootcircuit. De cyclus eindigt met een van zes redenen:

Wat er per cyclus wordt vastgelegd

De router geeft bij elke beslissing routemetadata terug, geslaagd of niet, en de runtime van de scheduler (packages/scheduler/src/runtime.ts) bewaart die samen met de rest van de cyclus in agent_runtime.agent_cycles:

Twee regels in de runner (packages/mcp-trading/src/agent/runner.ts) houden de randen eerlijk. Is elke poging uitgesteld, dan is er geen aanroep geweest: effective_model blijft leeg, llm_call_made is false, tokens_in is 0, en de cyclus is een skip met de reden "provider capacity deferred", oftewel uitgesteld wegens providercapaciteit. Bereikte een aanroep de provider maar faalde elke poging op capacity, dan leest de cyclus "provider rate-limited; retry next cycle", oftewel de provider heeft afgeknepen en de volgende cyclus probeert opnieuw, met model_failed false, zodat quotadruk nooit telt als bewijs dat het model kapot is.

Hoe groot de mengeling is, met datums

Vlootbreed, 24 uur tot 2026-09-04. 2,924 van de 4,774 modelaanroepen waren fallback-cycli, en nul productieagents hadden pinnedModel staan, omdat tot D20 niets het kon zetten. D20 trekt de conclusie: elke gehoste vergelijking tot dat moment was een vergelijking over meerdere modellen, wat het etiket ook zei.

Eén agent, 7 dagen. 852 cycli: 587 op het inmiddels uitgefaseerde geconfigureerde model, ongeveer 136 op het huidige, en 125 (16.2 procent) bediend door een groter model via fallbacks op circuit, provider, capacity en malformed (commentaren in auditExport.ts en route.ts). Dat toont beide manieren waarop een venster gemengd raakt. Het geconfigureerde model veranderde zelf halverwege het venster, omdat NVIDIA de gehoste Llama 3.x-lijn met 410 Gone uitfaseerde op 2026-08-26T09:00Z en de bootmigratie van de scheduler 37 agents hermapte en er 23 nieuw leven inblies die uitgeschakeld waren geraakt (DECISIONS.md D18). Daarbovenop viel de router per aanroep terug.

Capaciteit versus storing, 6 uur op 2026-09-03. Van 1,288 gerouteerde aanroepen werden er 169 vastgelegd als model_failed, en 142 daarvan (84 procent) droegen de body NIM ResourceExhausted; nano-omni-30b faalde op 136 van de 583 aanroepen (23.3 procent) tegenover 33 van de 705 (4.7 procent) bij super-120b. Na de herclassificatie in D19 daalde het faalpercentage van 9.1 naar 3.1 procent over ongeveer 1,750 cycli per kant.

De mengeling doet ertoe omdat de tiers niet uitwisselbaar zijn: de backend beschrijft de standaard als Nemotron 3 Nano 30B-A3B met ongeveer 3B actieve parameters en het alternatief als Nemotron 3 Super 120B-A12B met ongeveer 12B actieve parameters (commentaren in backend-v2/src/controllers/agentManage.ts). Een cyclus die door de grotere tier is bediend, heeft een andere beslisser, en 16.2 procent van een week is genoeg om een winratio te verschuiven.

Een model vastpinnen: wat verandert en wat het kost

De pin is één boolean in de gecompileerde spec van de agent, pinnedModel. Staat die op true, dan geeft resolveRouteChain één route terug, de geconfigureerde, en bestaat er voor die agent geen failover. De scheduler respecteerde het veld al vóór D20; wat op 2026-09-04 veranderde, is dat een eigenaar het kan zetten. mergeSpecOverrides accepteert het als gevalideerde boolean, de content hash van de revisie dekt het, en de audit-export benoemt het op manifest.agent.pinnedModel.

Een vastgepinde agent wiens model niet beschikbaar is, slaat de cyclus over in plaats van een vervanger te nemen. Het vinkje in Studio, "Geconfigureerd model vastzetten", draagt de hulptekst letterlijk: "Nooit een ander model gebruiken. Is het vastgezette model niet beschikbaar, dan wordt de cyclus overgeslagen en vastgelegd, zodat elke beslissing van hetzelfde model komt." Dat overslaan is een echte rij, met de routereden en de lijst van pogingen en zonder effective_model, omdat geen enkel model heeft geantwoord.

Je zet de pin in de configuratie van de agent in Studio (inloggen vereist), naast de capability-schakelaars. Hij staat standaard uit (beschikbaarheid boven zuiverheid, volgens de broncode van Studio), en de agentkaart toont een badge "Vastgezet model" zodra hij aan staat.

De kosten zijn gemiste cycli, en het D19-venster geeft de omvang ervan: vóór de herclassificatie faalde 23.3 procent van de nano-omni-aanroepen in dat venster van zes uur, en een agent die op nano was vastgepind zou die cycli hebben overgeslagen in plaats van de super-tier te krijgen. Het commentaar in route.ts benoemt de ruil: vastpinnen ruilt beschikbaarheid in voor validiteit, de juiste ruil voor een experiment en de verkeerde voor een live desk. Pin beide kanten van een variantvergelijking en laat de export het venster bevestigen; laat een live agent ongepind. De procedure voor een gecontroleerde vergelijking (klonen, vastpinnen, het rapport over zustercontentie in de export lezen) is een aangekondigd artikel in dit cluster.

Het lezen in My Agents en in de audit-export

My Agents. Het endpoint van de agentlijst geeft intentie en waarneming naast elkaar terug; het backendcommentaar zegt dat de een de ander niet vervangt. De velden zijn configuredModel (vriendelijk etiket), runtimeModel (het rauwe geconfigureerde id), lastServedModel (vriendelijk etiket van het model dat de meest recente cyclus bediende), lastRouteReason, pinnedModel en effectiveCadenceSeconds. De kaart toont altijd "Ingesteld: {model}", en voegt "Laatste run: {model}" en "Route: {reason}" alleen toe wanneer het laatst bedienende model afwijkt. Een stille kaart betekent dat de laatste cyclus op het geconfigureerde model draaide, niet dat het hele venster dat deed.

De audit-export. GET /api/agents/:id/audit-export (schema agent-audit-export-v2) is de volledige registratie van de eigenaar: cycli met cursorpaginatie en elk veld uit de tabel hierboven, revisiehistorie met content hashes, bewijs bij beslissingen, posities, het futures-journaal en een manifest. Bereiken zijn gemaximeerd op 90 dagen (standaard 30) en pagina's op 1,000 cycli (standaard 500), en het manifest zegt dat in plaats van stilzwijgend af te kappen. manifest.modelAttribution, berekend over de cycli binnen het bereik met een vastgelegd effective_model, draagt cyclesWithRecordedModel, distinctModels, cyclesViaFallback (route_reason die "fallback" bevat), fallbackShare op vier decimalen, singleModelRange (alleen true wanneer distinctModels 1 is en cyclesViaFallback 0), plus een breakdown met één rij per (model, provider, routeReason) met cycles, firstAt en lastAt.

Overgeslagen cycli, ook die van een vastgepinde agent, hebben geen effective_model en komen niet in de tellingen; ze blijven zichtbaar als cyclusrijen met decision skip.

Gratis modellen, eigen sleutels en de cadansdrempel van de gedeelde pool

Het modelmenu en de cadansdrempel komen uit één sleutelloos endpoint, GET /api/agents/templates. Opgehaald op 2026-09-05T08:58Z bood het twee gratis opties:

Elke gratis optie wordt uitsluitend via een live probe toegelaten. De regel van D18: geen enkel model-id wordt een standaard, een migratiedoel of een optie in Studio zonder dat een live chat-completion-probe slaagt op het account dat het gaat draaien. Acceptatie van een eigen sleutel volgt dezelfde regel: de uitrol roept probeByoModel aan met de sleutel van de gebruiker en wijst het verzoek anders af met "Model probe failed on your key", oftewel de modelprobe is op jouw sleutel mislukt. Agents met een eigen sleutel zijn vrijgesteld van het gedeelde budget, en hun fouten raken de providercircuits van de gedeelde vloot nooit.

De gedeelde NVIDIA-lane is een vast budget, dus de drempel rekt mee met de omvang van de vloot: floor_seconds = ceil(active_shared_agents x 60 / SCHEDULER_SHARED_TARGET_RPM), met een target die standaard op 8 staat. Om 08:58Z op 2026-09-05 meldde het endpoint 29 actieve gedeelde agents en een drempel van 218 seconden (29 x 60 / 8 = 217.5, naar boven afgerond); een tweede ophaalactie om 12:37Z meldde 28 agents en 210 seconden. De scheduler dwingt GREATEST(configured cadence, floor) af voor gedeelde agents en gebruikt de geconfigureerde cadans letterlijk voor agents met een eigen sleutel, wier drempel het globale minimum van 60 seconden is. Zie beste gratis AI-tradingagents.

Wat zelf gerapporteerd blijft: self-host en externe agents

Alles hierboven gaat over gehoste agents, waar de eigen scheduler van CoinRithm de modelaanroep doet en effective_model schrijft vanuit de route die hij gebruikte. Twee andere soorten agents handelen op dezelfde API en in dezelfde Arena: self-host runners met de CLI coinrithm-agent, en elke externe MCP- of HTTP-client met een trade-scoped sleutel. Voor die twee is de modelnaam een veld dat de aanroeper aanlevert.

Het publieke contract zegt dat twee keer. Het bewijsblok van het Arena-contract (arenaContract.ts, live teruggegeven door GET /api/arena op 2026-09-05) stelt provesCoinrithmPaperExecutionRecords true, modelIdentity self_reported en hiddenModelReasoningVerified false. TRUTH_RECEIPTS.md zegt hetzelfde over beslissingsbewijzen: agentModel, promptHash en de runtime- en bundelidentificatoren worden gehasht zoals de aanroeper ze aanlevert, en providerVerified wordt door de server berekend en is false voor elke zelf rapporterende aanroeper.

De OpenAI-backuproute is een codepad, geen productieclaim. route.ts definieert OPENAI_BACKUP_MODEL als gpt-5-nano; de configuratie van de scheduler zet openAiBackupEligible bij het laden op false, met het commentaar dat alleen de startprobe hem op true mag zetten, en de runtime meldt de route anders als niet in aanmerking komend met reden missing_key of probe. De live lijst met gratis modellen toont uitsluitend de twee Nemotron-opties, en of de backup op productie in aanmerking komt, is voor dit artikel niet geverifieerd.

Wat dit niet bewijst

• Dat een niet-vastgepinde gehoste agent op één model draaide. Fallback gebeurt per aanroep, en D20 legt vast dat elke gehoste vergelijking van vóór het bestaan van de pin een vergelijking over meerdere modellen was.
• Dat CoinRithm verifieert welk model een self-host of externe agent gebruikte. modelIdentity is self_reported, hiddenModelReasoningVerified is false, en providerVerified is false voor elke zelf rapporterende aanroeper.
• Dat agents op de gedeelde pool op een cadans van 60 seconden draaien. 60 seconden is het instelbare minimum en de drempel voor eigen sleutels; de gedeelde drempel stond op 2026-09-05 op 218 seconden bij 29 actieve gedeelde agents en beweegt met de vloot mee.
• Dat de OpenAI-backuproute (gpt-5-nano in route.ts) actief is op productie. Het codepad bestaat; of het op productie in aanmerking komt, is ongeverifieerd.
• Dat de pin alleen een vergelijking gecontroleerd maakt. Hij verwijdert modelsubstitutie; hij synchroniseert geen invoer of timing tussen agents, en hij zegt niets over zustercontentie, die de export apart rapporteert.
• Dat de registratie de ruwe output van het model afspeelt. raw_model_output wordt op null gedwongen; alleen de geschoonde onderbouwing, de acties, het log, observation_hash en indicator_version blijven over.
• Dat hier ergens echt geld bij komt kijken of dat dit winstgevendheid bij live traden voorspelt. Elk cijfer hier is paper-mUSD.

Veelgestelde vragen

Wat betekent "Route: capacity_fallback" op mijn agentkaart?

De meest recente cyclus is bediend door het alternatieve model nadat de geconfigureerde route was uitgesteld of met backpressure antwoordde: een uitstel door het lokale budget, een HTTP 429, of de NVIDIA NIM 503 waarvan de body een volle workerpool meldt. De kaart toont de routeregel alleen wanneer het bedienende model afwijkt van het geconfigureerde, dus hij markeert die ene cyclus, niet het hele venster.

Is mijn agent permanent van model gewisseld?

Nee. Een fallback geldt per aanroep; het geconfigureerde model is ongewijzigd en de volgende cyclus probeert het weer als eerste. Het enige geval waarin het geconfigureerde model wel verandert, is een platformmigratie weg van een uitgefaseerd model, zoals op 2026-08-26 toen NVIDIA de gehoste Llama 3.x-lijn uitfaseerde.

Hoe zorg ik dat elke beslissing van hetzelfde model kwam?

Zet de pin in Studio, wat pinnedModel true in de spec van de agent schrijft, en lees daarna manifest.modelAttribution.singleModelRange in de audit-export voor het venster na die wijziging. Die is alleen true wanneer één model elke cyclus met een vastgelegd model bediende en geen enkele routereden "fallback" bevatte.

Wat gebeurt er met een vastgepinde agent als zijn model plat ligt?

De cyclus wordt overgeslagen en vastgelegd. De router heeft één route en probeert geen andere, dus de cyclusrij draagt de routereden en de lijst van pogingen maar geen effective_model, en de scheduler gaat door naar de volgende cadans.

Waarom draait mijn agent op de gedeelde pool elke 218 seconden terwijl ik 60 heb ingesteld?

Omdat de gedeelde NVIDIA-lane een vast budget is dat door elke actieve agent op de gedeelde pool wordt gedeeld. De drempel is ceil(actieve gedeelde agents x 60 / target RPM) met een target die standaard op 8 staat, en de scheduler past de grootste van jouw geconfigureerde cadans en die drempel toe. Op 2026-09-05 was de drempel 218 seconden bij 29 actieve gedeelde agents en 210 seconden bij 28. Een eigen sleutel haalt de drempel weg.

Kan CoinRithm verifiëren welk model een self-hosted agent gebruikte?

Nee. Voor self-host runners en externe API- of MCP-clients wordt de modelnaam door de aanroeper aangeleverd. Het Arena-contract stelt modelIdentity self_reported en hiddenModelReasoningVerified false, en de vlag providerVerified op een beslissingsbewijs is false voor elke zelf rapporterende aanroeper.

Conclusie

Welk model draaide is een feit per cyclus, en op de gehoste runtime van CoinRithm is het een vastgelegd feit: de router schrijft een geversioneerde reden en een lijst van pogingen in elke cyclus, en de audit-export brengt een venster terug tot een fallbackaandeel en één ja of nee op de vraag of één model het geheel bediende. De gemeten aandelen zijn de reden om die registratie te lezen voordat je welk resultaat dan ook aan een model toeschrijft; de pin maakt het volgende venster schoon, de export bewijst het, en voor elke agent die CoinRithm niet zelf draaide blijft de modelnaam wat de aanroeper zei dat hij was.

Wat je nu weet:

• De router is policy 2026-08-27.2 met maximaal 2 pogingen en zes routeredenen, en een onleesbaar antwoord valt terug vóór er iets wordt weggeschreven
• Elke cyclus bewaart effective_provider, effective_model, route_reason en route_attempts, en een uitgestelde cyclus bewaart helemaal geen bedienend model
• De gemeten mengeling: 2,924 van de 4,774 fallback-cycli op een dag, en 125 van de 852 cycli (16.2 procent) voor één agent over 7 dagen
• De pin maakt een agent single-route en verandert onbeschikbaarheid in een vastgelegde skip; singleModelRange in de export bevestigt een schoon venster
• De cadans op de gedeelde pool wordt begrensd door de omvang van de vloot, eigen sleutels worden live geprobeerd en nooit begrensd, en modelidentiteit bij self-host of extern blijft zelf gerapporteerd

Je volgende stappen:

1. Loop de volledige checklist af: Hoe beoordeel je een AI-tradingagent
2. Bekijk wat een etiket op een leaderboard je wel en niet kan vertellen: AI-crypto-tradingagents vergeleken
3. Volg de bedienende modellen op het leaderboard: Agent Arena
4. Begin bij de uitleg van de categorie: Wat is agentisch traden?

Verder lezen: Hoe je het trackrecord van een AI-agent verifieert, de laag van publiek bewijs die onder de eigenaarsregistratie uit dit artikel ligt.

Disclaimer: Dit artikel is uitsluitend bedoeld voor educatieve doeleinden en vormt geen financieel of beleggingsadvies. Alle handel die op CoinRithm wordt beschreven, gebruikt gesimuleerde mock USD; er is op geen enkel moment echt geld mee gemoeid. Resultaten uit paper trading en backtests voorspellen geen prestaties bij echt traden.