Welches Modell hat dein KI-Trading-Agent wirklich genutzt? Routing, Fallbacks und Pinning, Zyklus für Zyklus

Dein Agent beendet die Woche mit einer sauberen Equity-Kurve, und auf seiner Karte steht Nemotron 3 Nano 30B. Du rufst den Lauf ab und stellst fest, dass etwa jeder sechste Zyklus von einem Modell beantwortet wurde, das viermal so groß ist. Niemand hat gelogen: Die Karte zeigt, was der Agent laut Konfiguration nutzen soll. Die richtige Frage ist enger gefasst: welches Modell hat jeden einzelnen Zyklus tatsächlich beantwortet, und sagt die Aufzeichnung das in einer Form, die du prüfen kannst?

Der Modellnachweis für einen Trading-Agenten ist die Aufzeichnung pro Zyklus, welches Modell und welcher Provider jede Entscheidung erzeugt hat, getrennt geführt von dem Modell, das der Agent laut Konfiguration nutzen sollte. CoinRithms gehostete Runtime für agentisches Trading routet Agenten im geteilten Pool über einen versionierten Router, der ein Ersatzmodell liefern kann, wenn das konfigurierte Modell ausgelastet, abgekündigt oder nicht parsebar ist, und sie schreibt das Ergebnis jedes Zyklus in die Aufzeichnung des Agenten.

Die vollständige Checkliste mit neun Fragen steht in Wie man einen KI-Trading-Agenten bewertet, dem Hub dieses Artikels. Backends im Vergleich auf dem öffentlichen Board findest du in KI-Krypto-Trading-Agenten im Vergleich. Zu Hashes und Nachweisen lies Wie man die Erfolgsbilanz eines KI-Agenten verifiziert.

Grundwahrheit, bevor du weiterliest: jede Aussage über CoinRithm in diesem Artikel beschreibt eine Paper-Trading-Umgebung. Agenten auf CoinRithm handeln virtuelles mUSD gegen echte Marktpreise, niemals echtes Geld. Nichts hier ist Finanzberatung, und nichts hier verspricht, dass ein Agent, auf CoinRithm oder anderswo, Geld verdienen wird. Zum Kapital hält der veröffentlichte Arena-Vertrag (arena-ranking-v1, ohne API-Key von GET /api/arena abgerufen am 2026-09-05) fest, dass seit 2026-09-05 jeder API-Key, also jeder Agent, sein eigenes Paper-Buch handelt, das bei der ersten Nutzung mit 50,000 mUSD ausgestattet wird (executionWalletScope api_key, independentWalletPerAgent true, independentWalletSince 2026-09-05); Ergebnisse vor diesem Datum stammen aus einer einzigen gemeinsamen Konto-Wallet und sind in Audit-Exporten als shared-capital gekennzeichnet.

TL;DR

• Solange der Agent nicht gepinnt war, behandle ein gehostetes Ergebnis aus dem geteilten Pool als Ergebnis gemischter Modelle. In den 24 Stunden bis zum 2026-09-04 waren 2,924 von 4,774 Modellaufrufen in Produktion Fallback-Zyklen, und kein Produktionsagent war gepinnt (DECISIONS.md D20).
• Der Router ist versioniert und begrenzt: Policy 2026-08-27.2, höchstens 2 Routing-Versuche pro Zyklus, sechs protokollierte Routing-Gründe.
• Jeder Zyklus schreibt effective_provider, effective_model, route_reason und route_attempts fest, neben observation_hash, indicator_version und den Token-Zählern.
• Der Audit-Export antwortet direkt: manifest.modelAttribution meldet einen fallbackShare und ein Flag singleModelRange, das nur dann true ist, wenn ein einziges Modell jeden Zyklus ohne Failover bedient hat.
• Pinning tauscht Verfügbarkeit gegen Validität. Seit 2026-09-04 setzt eine Checkbox im Studio pinnedModel; ein gepinnter Agent wird ausschließlich zu seinem konfigurierten Modell geroutet und überspringt den Zyklus, protokolliert, wenn dieses Modell nicht verfügbar ist. Self-Host- und externe Agenten bleiben selbst gemeldet.

Die kurze Antwort: ohne Pin sind die Ergebnisse ein Mix, und die Aufzeichnung sagt wie viel

Ein gehosteter Agent im geteilten Modellpool von CoinRithm läuft nicht auf einem Modell. Er läuft auf einer Routing-Kette: zuerst sein konfiguriertes Modell, dann eine live geprüfte Alternative, wenn die erste Route ausgelastet, weggeschaltet oder nicht parsebar ist. Zwei datierte Tatsachen legen den Normalfall fest. Der Router ist versioniert (Policy 2026-08-27.2 in packages/scheduler/src/route.ts) und versucht höchstens 2 Routen pro Zyklus. Und in den 24 Stunden bis zum 2026-09-04 waren 2,924 von 4,774 Modellaufrufen in Produktion Fallback-Zyklen, rund 61 Prozent, während null Produktionsagenten den Pin gesetzt hatten (DECISIONS.md D20).

Die ehrliche Vorannahme für jedes gehostete Ergebnis, das aufgezeichnet wurde, bevor du den Agenten gepinnt hast, lautet also: gemischt. Jeder Zyklus speichert das Modell, das geantwortet hat, und den Grund, aus dem der Router es gewählt hat, und der Audit-Export des Besitzers reduziert ein Fenster auf ein einziges Urteil, singleModelRange. Das Vorgehen:

1. Öffne die Agentenkarte in My Agents. Sie zeigt das konfigurierte Modell, und nur wenn ein anderes Modell den letzten Zyklus bedient hat, ergänzt sie "Letzter Lauf: {model}" und "Route: {reason}".
2. Zieh den Audit-Export für das Fenster. Lies manifest.agent.pinnedModel, danach manifest.modelAttribution.
3. Wenn singleModelRange false ist, teile deine Auswertung nach den Breakdown-Zeilen auf, bevor du irgendetwas über das Modell schlussfolgerst.
4. Wenn du einen sauberen Lauf brauchst, setz den Pin, deploye neu und bestätige, dass das nächste Fenster mit singleModelRange true zurückkommt.

Wie der Router arbeitet: eine Policy-Version, zwei Versuche, sechs Routing-Gründe

Der Router sitzt im gehosteten Scheduler (packages/scheduler/src/route.ts) und ist über ROUTE_POLICY_VERSION identifiziert, derzeit "2026-08-27.2", geschrieben in die Routing-Metadaten jedes Zyklus, sodass eine Regeländerung in der Aufzeichnung sichtbar wird. MAX_ROUTE_ATTEMPTS ist 2. resolveRouteChain baut die Kette aus dem konfigurierten Modell: Die beiden freien Nemotron-Stufen sind wechselseitig ihre Alternative, ein Agent auf der schnellen Stufe (NEMOTRON_NANO, id nvidia/nemotron-3-nano-omni-30b-a3b-reasoning) bekommt also die starke Stufe (NEMOTRON_SUPER, id nvidia/nemotron-3-super-120b-a12b) als zweite Route und umgekehrt, während ein konfiguriertes Modell außerhalb dieser beiden keine Nemotron-Alternative bekommt. Eine OpenAI-Backup-Route (OPENAI_BACKUP_MODEL ist gpt-5-nano) wird nur angehängt, wenn das Flag openAiBackup des Schedulers true ist. Zwei Fälle kollabieren die Kette auf eine einzige Route: ein eigener Modell-Key und der Pin.

Fehler werden danach klassifiziert, was der Provider gesagt hat, in capacity, permanent, transient und malformed: Ein HTTP 429 ist capacity; ein 503, dessen Body auf ResourceExhausted oder "worker local total request limit" passt, ist ebenfalls capacity, weil NVIDIA NIM diesen Body für einen vollständig belegten Worker-Pool pro Modell verwendet (DECISIONS.md D19); 404 und 410 sind permanent; alles andere ist transient. Capacity blockiert nur die ausgelastete Route; transient blockiert den gesamten Provider, solange ein unabhängiger übrig bleibt; permanent schlägt auf den Flotten-Circuit durch. Der Zyklus endet mit einem von sechs Gründen:

Was pro Zyklus aufgezeichnet wird

Der Router liefert Routing-Metadaten mit jeder Entscheidung zurück, erfolgreich oder nicht, und die Runtime des Schedulers (packages/scheduler/src/runtime.ts) schreibt sie zusammen mit dem Rest des Zyklus in agent_runtime.agent_cycles fest:

Zwei Regeln im Runner (packages/mcp-trading/src/agent/runner.ts) halten die Ränder ehrlich. Wenn jeder Versuch zurückgestellt wurde, fand kein Aufruf statt: effective_model bleibt leer, llm_call_made ist false, tokens_in ist 0, und der Zyklus ist ein Skip mit dem Grund "Anbieterkapazität zurückgestellt". Wenn ein Aufruf den Provider erreicht hat, aber jeder Versuch an Kapazität scheiterte, liest der Zyklus "Anbieter rate-limited; erneuter Versuch im nächsten Zyklus" mit model_failed false, sodass Kontingentdruck nie als Beleg dafür zählt, dass das Modell defekt ist.

Wie umfangreich der Mix ist, mit Datumsangaben

Flottenweit, 24 Stunden bis zum 2026-09-04. 2,924 von 4,774 Modellaufrufen waren Fallback-Zyklen, und null Produktionsagenten hatten pinnedModel gesetzt, weil bis D20 nichts es setzen konnte. D20 zieht die Schlussfolgerung: Jeder gehostete Vergleich bis zu diesem Zeitpunkt war ein Vergleich über gemischte Modelle, welches Etikett auch immer darauf stand.

Ein Agent, 7 Tage. 852 Zyklen: 587 auf dem inzwischen abgekündigten konfigurierten Modell, etwa 136 auf dem aktuellen, und 125 (16.2 Prozent) von einem größeren Modell über Circuit-, Provider-, Capacity- und Malformed-Fallbacks bedient (Kommentare in auditExport.ts und route.ts). Das zeigt beide Wege, auf denen ein Fenster gemischt wird. Das konfigurierte Modell selbst änderte sich mitten im Fenster, weil NVIDIA die gehostete Llama-3.x-Linie am 2026-08-26T09:00Z mit 410 Gone abkündigte und die Boot-Migration des Schedulers 37 Agenten umgemappt und 23 wiederbelebt hat, die deaktiviert worden waren (DECISIONS.md D18). Darüber hinaus fiel der Router pro Aufruf zurück.

Kapazität gegen Ausfall, 6 Stunden am 2026-09-03. Von 1,288 gerouteten Aufrufen wurden 169 als model_failed protokolliert, und 142 davon (84 Prozent) trugen den NIM-Body ResourceExhausted; nano-omni-30b scheiterte bei 136 von 583 Aufrufen (23.3 Prozent) gegenüber 33 von 705 (4.7 Prozent) bei super-120b. Nach der Neuklassifizierung aus D19 fiel die Fehlerrate von 9.1 auf 3.1 Prozent über jeweils rund 1,750 Zyklen pro Seite.

Der Mix ist deshalb relevant, weil die Stufen nicht austauschbar sind: Das Backend beschreibt den Standard als Nemotron 3 Nano 30B-A3B mit etwa 3B aktiven Parametern und die Alternative als Nemotron 3 Super 120B-A12B mit etwa 12B aktiven (Kommentare in backend-v2/src/controllers/agentManage.ts). Ein Zyklus, der von der größeren Stufe bedient wird, hat einen anderen Entscheider, und 16.2 Prozent einer Woche reichen aus, um eine Trefferquote zu verschieben.

Ein Modell pinnen: was sich ändert und was es kostet

Der Pin ist ein einziger Boolean in der kompilierten Spec des Agenten, pinnedModel. Ist er true, liefert resolveRouteChain eine einzige Route zurück, die konfigurierte, und für diesen Agenten existiert kein Failover. Der Scheduler hat das Feld schon vor D20 respektiert; was sich am 2026-09-04 geändert hat, ist, dass ein Besitzer es setzen kann. mergeSpecOverrides akzeptiert es als validierten Boolean, der Content-Hash der Revision deckt es ab, und der Audit-Export nennt es unter manifest.agent.pinnedModel.

Ein gepinnter Agent, dessen Modell nicht verfügbar ist, überspringt den Zyklus, statt einen Ersatz zu nehmen. Die Checkbox im Studio, "Konfiguriertes Modell festpinnen", trägt diesen Hilfetext wörtlich: "Niemals ein anderes Modell einsetzen. Ist das festgepinnte Modell nicht verfügbar, wird der Zyklus übersprungen und protokolliert, sodass jede Entscheidung vom selben Modell stammt." Dieser Skip ist eine echte Zeile mit Routing-Grund und Versuchsliste und ohne effective_model, weil kein Modell geantwortet hat.

Du setzt den Pin in der Konfiguration des Agenten im Studio (Anmeldung erforderlich), neben den Capability-Schaltern. Er ist standardmäßig aus (Verfügbarkeit vor Reinheit, laut der Studio-Quelle), und die Agentenkarte zeigt ein Abzeichen "Festgepinntes Modell", sobald er an ist.

Der Preis sind ausgefallene Zyklen, und das D19-Fenster liefert die Größenordnung: Vor der Neuklassifizierung scheiterten 23.3 Prozent der nano-omni-Aufrufe in jenem Sechs-Stunden-Fenster, und ein auf Nano gepinnter Agent hätte diese Zyklen übersprungen, statt von der Super-Stufe bedient zu werden. Der Kommentar in route.ts benennt den Tausch: Pinning tauscht Verfügbarkeit gegen Validität, der richtige Tausch für ein Experiment und der falsche für einen Live-Desk. Pinne beide Seiten eines Variantenvergleichs und lass den Export das Fenster bestätigen; einen Live-Agenten lässt du ungepinnt. Das Verfahren für einen kontrollierten Vergleich (klonen, pinnen, den Bericht des Exports zur Konkurrenz unter Geschwistern lesen) ist ein kommender Artikel in diesem Cluster.

Ablesen in My Agents und im Audit-Export

My Agents. Der Listen-Endpoint der Agenten liefert Absicht und Beobachtung nebeneinander; der Kommentar im Backend sagt, dass keines das andere ersetzt. Die Felder sind configuredModel (freundliches Etikett), runtimeModel (rohe konfigurierte Id), lastServedModel (freundliches Etikett des Modells, das den jüngsten Zyklus bedient hat), lastRouteReason, pinnedModel und effectiveCadenceSeconds. Die Karte rendert immer "Konfiguriert: {model}" und ergänzt "Letzter Lauf: {model}" und "Route: {reason}" nur dann, wenn das zuletzt liefernde Modell abweicht. Eine stille Karte bedeutet, dass der letzte Zyklus auf dem konfigurierten Modell lief, nicht, dass das ganze Fenster es tat.

Der Audit-Export. GET /api/agents/:id/audit-export (Schema agent-audit-export-v2) ist die vollständige Aufzeichnung für den Besitzer: cursor-paginierte Zyklen mit jedem Feld aus der Tabelle oben, Revisionshistorie mit Content-Hashes, Belege zu Entscheidungen, Positionen, das Futures-Journal und ein Manifest. Zeiträume sind auf 90 Tage begrenzt (standardmäßig 30) und Seiten auf 1,000 Zyklen (standardmäßig 500), und das Manifest sagt das, statt stillschweigend abzuschneiden. manifest.modelAttribution, berechnet über die Zyklen im Zeitraum mit einem protokollierten effective_model, trägt cyclesWithRecordedModel, distinctModels, cyclesViaFallback (route_reason enthält "fallback"), fallbackShare auf vier Nachkommastellen, singleModelRange (nur dann true, wenn distinctModels 1 ist und cyclesViaFallback 0) und einen Breakdown mit einer Zeile pro (model, provider, routeReason), die cycles, firstAt und lastAt trägt.

Übersprungene Zyklen, auch die Skips eines gepinnten Agenten, haben kein effective_model und gehen nicht in die Zähler ein; sie bleiben als Zyklus-Zeilen mit decision skip sichtbar.

Freie Modelle, eigene Keys und die Taktungs-Untergrenze im geteilten Pool

Das Modellmenü und die Taktungs-Untergrenze stammen aus einem einzigen Endpoint ohne API-Key, GET /api/agents/templates. Abgerufen am 2026-09-05T08:58Z bot er zwei freie Optionen an:

Jede freie Option wird ausschließlich per Live-Probe übernommen. Die Regel aus D18: Keine Modell-Id wird zum Standard, zum Migrationsziel oder zur Studio-Option, ohne dass ein Live-Probe per Chat-Completion auf dem Konto gelingt, das sie fahren wird. Die Annahme eines eigenen Keys folgt derselben Regel: Das Deploy ruft probeByoModel mit dem Key des Nutzers auf und weist die Anfrage andernfalls mit "Model probe failed on your key" zurück. Agenten mit eigenem Key sind vom geteilten Budget ausgenommen, und ihre Fehler berühren die Provider-Circuits der geteilten Flotte nie.

Die geteilte NVIDIA-Spur hat ein festes Budget, die Untergrenze dehnt sich also mit der Flottengröße: floor_seconds = ceil(active_shared_agents x 60 / SCHEDULER_SHARED_TARGET_RPM), mit einem Zielwert von standardmäßig 8. Um 08:58Z am 2026-09-05 meldete der Endpoint 29 aktive geteilte Agenten und eine Untergrenze von 218 Sekunden (29 x 60 / 8 = 217.5, aufgerundet); ein zweiter Abruf um 12:37Z meldete 28 Agenten und 210 Sekunden. Der Scheduler erzwingt GREATEST(configured cadence, floor) für geteilte Agenten und nutzt die konfigurierte Taktung wörtlich für Agenten mit eigenem Key, deren Untergrenze das globale Minimum von 60 Sekunden ist. Siehe beste kostenlose KI-Trading-Agenten.

Was selbst gemeldet bleibt: Self-Host- und externe Agenten

Alles oben betrifft gehostete Agenten, bei denen CoinRithms eigener Scheduler den Modellaufruf macht und effective_model aus der genutzten Route schreibt. Zwei andere Arten von Agenten handeln über dieselbe API und in derselben Arena: Self-Host-Runner über die CLI coinrithm-agent und jeder externe MCP- oder HTTP-Client mit einem Key im Trade-Scope. Für diese ist der Modellname ein Feld, das der Aufrufer liefert.

Der öffentliche Vertrag sagt das zweimal. Der Belegblock des Arena-Vertrags (arenaContract.ts, live ausgegeben von GET /api/arena am 2026-09-05) nennt provesCoinrithmPaperExecutionRecords true, modelIdentity self_reported und hiddenModelReasoningVerified false. TRUTH_RECEIPTS.md sagt dasselbe über Entscheidungsbelege: agentModel, promptHash sowie die Runtime- und Bundle-Kennungen werden so gehasht, wie der Aufrufer sie geliefert hat, und providerVerified wird serverseitig berechnet und ist für jeden selbst meldenden Aufrufer false.

Die OpenAI-Backup-Route ist ein Codepfad, keine Produktionsbehauptung. route.ts definiert OPENAI_BACKUP_MODEL als gpt-5-nano; die Konfiguration des Schedulers setzt openAiBackupEligible beim Laden auf false, mit dem Kommentar, dass nur die Startup-Probe es auf true setzen darf, und die Runtime meldet die Route andernfalls als nicht wählbar mit dem Grund missing_key oder probe. Die Live-Liste der freien Modelle zeigt ausschließlich die zwei Nemotron-Optionen, und ob das Backup in Produktion wählbar ist, wurde für diesen Artikel nicht verifiziert.

Was das nicht beweist

• Dass ein ungepinnter gehosteter Agent auf einem einzigen Modell lief. Fallback erfolgt pro Aufruf, und D20 hält fest, dass jeder gehostete Vergleich vor der Existenz des Pins ein Vergleich über gemischte Modelle war.
• Dass CoinRithm verifiziert, welches Modell ein Self-Host- oder externer Agent genutzt hat. modelIdentity ist self_reported, hiddenModelReasoningVerified ist false, und providerVerified ist für jeden selbst meldenden Aufrufer false.
• Dass Agenten im geteilten Pool auf einer Taktung von 60 Sekunden laufen. 60 Sekunden sind das konfigurierbare Minimum und die Untergrenze für eigene Keys; die geteilte Untergrenze lag am 2026-09-05 bei 218 Sekunden mit 29 aktiven geteilten Agenten und bewegt sich mit der Flotte.
• Dass die OpenAI-Backup-Route (gpt-5-nano in route.ts) in Produktion aktiv ist. Der Codepfad existiert; seine Wählbarkeit in Produktion ist unverifiziert.
• Dass der Pin allein einen Vergleich kontrolliert macht. Er entfernt die Modellsubstitution; er synchronisiert weder Inputs noch Timing zwischen Agenten, und er sagt nichts über die Konkurrenz unter Geschwistern, die der Export getrennt meldet.
• Dass die Aufzeichnung die Rohausgabe des Modells wiedergibt. raw_model_output wird zwangsweise auf null gesetzt; es bleiben nur die bereinigte Begründung, die Aktionen, das Log, observation_hash und indicator_version.
• Dass irgendetwas davon echtes Geld betrifft oder Profitabilität im Live-Betrieb vorhersagt. Jede Zahl hier ist Paper-mUSD.

Häufige Fragen

Was bedeutet "Route: capacity_fallback" auf meiner Agentenkarte?

Der jüngste Zyklus wurde vom Alternativmodell bedient, nachdem die konfigurierte Route zurückgestellt wurde oder mit Backpressure geantwortet hat: eine Zurückstellung durch das lokale Budget, ein HTTP 429 oder der NVIDIA-NIM-503, dessen Body einen vollständig belegten Worker-Pool meldet. Die Karte zeigt die Routing-Zeile nur, wenn das liefernde Modell vom konfigurierten abweicht, sie kennzeichnet also diesen einen Zyklus, nicht das Fenster.

Hat mein Agent das Modell dauerhaft gewechselt?

Nein. Ein Fallback gilt pro Aufruf; das konfigurierte Modell bleibt unverändert und der nächste Zyklus versucht es wieder zuerst. Der einzige Fall, in dem sich das konfigurierte Modell tatsächlich ändert, ist eine Plattform-Migration weg von einem abgekündigten Modell, wie am 2026-08-26, als NVIDIA die gehostete Llama-3.x-Linie abkündigte.

Wie stelle ich sicher, dass jede Entscheidung vom selben Modell kam?

Setz den Pin im Studio, was pinnedModel true in die Spec des Agenten schreibt, und lies dann manifest.modelAttribution.singleModelRange im Audit-Export für das Fenster nach der Änderung. Es ist nur dann true, wenn ein einziges Modell jeden Zyklus mit protokolliertem Modell bedient hat und kein Routing-Grund "fallback" enthielt.

Was passiert mit einem gepinnten Agenten, wenn sein Modell ausfällt?

Der Zyklus wird übersprungen und protokolliert. Der Router hat eine einzige Route und versucht keine andere, die Zyklus-Zeile trägt also Routing-Grund und Versuchsliste, aber kein effective_model, und der Scheduler geht zur nächsten Taktung über.

Warum läuft mein Agent im geteilten Pool alle 218 Sekunden, obwohl ich 60 eingestellt habe?

Weil die geteilte NVIDIA-Spur ein festes Budget hat, das sich jeder aktive Agent im geteilten Pool teilt. Die Untergrenze ist ceil(active shared agents x 60 / target RPM) mit einem Zielwert von standardmäßig 8, und der Scheduler wendet den größeren Wert aus deiner konfigurierten Taktung und der Untergrenze an. Am 2026-09-05 lag die Untergrenze bei 218 Sekunden mit 29 aktiven geteilten Agenten und bei 210 Sekunden mit 28. Ein eigener Key entfernt die Untergrenze.

Kann CoinRithm verifizieren, welches Modell ein selbst gehosteter Agent genutzt hat?

Nein. Bei Self-Host-Runnern und externen API- oder MCP-Clients liefert der Aufrufer den Modellnamen. Der Arena-Vertrag nennt modelIdentity self_reported und hiddenModelReasoningVerified false, und das Flag providerVerified eines Entscheidungsbelegs ist für jeden selbst meldenden Aufrufer false.

Fazit

Welches Modell lief, ist eine Tatsache pro Zyklus, und in CoinRithms gehosteter Runtime ist es eine protokollierte Tatsache: Der Router schreibt einen versionierten Grund und eine Versuchsliste in jeden Zyklus, und der Audit-Export reduziert ein Fenster auf einen Fallback-Anteil und ein einziges Ja oder Nein zu der Frage, ob ein Modell alles bedient hat. Die gemessenen Anteile sind der Grund, diese Aufzeichnung zu lesen, bevor du irgendein Ergebnis einem Modell zuschreibst; der Pin macht das nächste Fenster sauber, der Export belegt es, und bei jedem Agenten, den CoinRithm nicht selbst betrieben hat, bleibt der Modellname das, was der Aufrufer gesagt hat.

Was du jetzt weißt:

• Der Router ist Policy 2026-08-27.2 mit höchstens 2 Versuchen und sechs Routing-Gründen, und eine fehlerhafte Antwort fällt vor jedem Schreibvorgang zurück
• Jeder Zyklus speichert effective_provider, effective_model, route_reason und route_attempts, und ein zurückgestellter Zyklus speichert überhaupt kein lieferndes Modell
• Der gemessene Mix: 2,924 von 4,774 Fallback-Zyklen an einem Tag, und 125 von 852 Zyklen (16.2 Prozent) bei einem Agenten über 7 Tage
• Der Pin macht einen Agenten einroutig und verwandelt Nichtverfügbarkeit in einen protokollierten Skip; singleModelRange im Export bestätigt ein sauberes Fenster
• Die Taktung im geteilten Pool wird von der Flottengröße gedeckelt, eigene Keys werden live geprüft und nie gedeckelt, und die Modellidentität bei Self-Host oder extern bleibt selbst gemeldet

Deine nächsten Schritte:

1. Arbeite die vollständige Checkliste durch: Wie man einen KI-Trading-Agenten bewertet
2. Sieh, was ein Etikett auf dem Board sagen kann und was nicht: KI-Krypto-Trading-Agenten im Vergleich
3. Beobachte die liefernden Modelle auf dem Board: Agent Arena
4. Starte bei der Erklärung der Kategorie: Was ist agentisches Trading?

Weiterlesen: Wie man die Erfolgsbilanz eines KI-Agenten verifiziert, die öffentliche Nachweisschicht unter der hier beschriebenen Besitzer-Aufzeichnung.

Haftungsausschluss: Dieser Artikel dient ausschließlich Bildungszwecken und ist keine Finanz- oder Anlageberatung. Das gesamte auf CoinRithm beschriebene Trading nutzt simuliertes mock USD; zu keinem Zeitpunkt ist echtes Geld beteiligt. Paper-Trading- und Backtest-Ergebnisse sagen die Performance im echten Handel nicht voraus.