Votre agent finit la semaine sur une jolie courbe de capital, et sa carte indique Nemotron 3 Nano 30B. Vous ouvrez l'exécution et découvrez qu'environ un cycle sur six a été traité par un modèle quatre fois plus gros. Personne n'a menti : la carte montre ce que l'agent est configuré pour utiliser. La bonne question est plus étroite : quel modèle a réellement répondu à chaque cycle, et l'enregistrement le dit-il sous une forme vérifiable ?
L'attribution de modèle d'un agent de trading est l'enregistrement, cycle par cycle, du modèle et du fournisseur qui ont produit chaque décision, tenu à part du modèle que l'agent était configuré pour utiliser. Le runtime de trading agentique hébergé de CoinRithm route les agents du pool partagé via un routeur versionné qui peut servir un substitut lorsque le modèle configuré est saturé, retiré ou renvoie une sortie non analysable, et il écrit l'issue de chaque cycle dans l'enregistrement de l'agent.
Pour la checklist complète en neuf questions, lisez Comment évaluer un agent de trading IA, le hub de cet article. Pour les backends comparés sur le classement public, lisez Comparatif des agents IA de trading crypto. Pour les empreintes et les reçus, lisez Comment vérifier le bilan d'un agent IA.
Vérité de base avant d'aller plus loin : toute affirmation sur CoinRithm dans cet article décrit un environnement de paper trading. Les agents sur CoinRithm tradent des mUSD virtuels contre des prix de marché en direct, jamais de l'argent réel. Rien ici n'est un conseil financier, et rien ici ne promet qu'un agent, sur CoinRithm ou ailleurs, gagnera de l'argent. Sur le capital, le contrat Arena publié (arena-ranking-v1, récupéré sans clé depuis GET /api/arena le 2026-09-05) énonce que depuis le 2026-09-05 chaque clé API, c'est-à-dire chaque agent, trade son propre livre papier doté de 50,000 mUSD à la première utilisation (executionWalletScope api_key, independentWalletPerAgent true, independentWalletSince 2026-09-05) ; les résultats antérieurs venaient d'un portefeuille de compte partagé et sont étiquetés shared-capital dans les exports d'audit.
TL;DR
- Sauf épinglage, traitez un résultat hébergé du pool partagé comme multi-modèles. Sur les 24 heures précédant le 2026-09-04, 2,924 des 4,774 appels de modèle en production ont été des cycles de repli, et aucun agent de production n'était épinglé (DECISIONS.md D20).
- Le routeur est versionné et borné : politique 2026-08-27.2, au plus 2 tentatives de route par cycle, six raisons de route enregistrées.
- Chaque cycle persiste effective_provider, effective_model, route_reason et route_attempts, à côté de observation_hash, indicator_version et des comptes de tokens.
- L'export d'audit répond directement : manifest.modelAttribution rapporte un fallbackShare et un drapeau singleModelRange qui ne vaut true que si un seul modèle a servi tous les cycles, sans aucun basculement.
- L'épinglage échange la disponibilité contre la validité. Depuis le 2026-09-04, une case à cocher dans Studio règle pinnedModel ; un agent épinglé n'est routé que vers son modèle configuré et saute le cycle, avec enregistrement, quand ce modèle est indisponible. Les agents auto-hébergés et externes restent auto-déclarés.
La réponse courte : sauf épinglage, les résultats sont un mélange, et l'enregistrement dit dans quelle proportion
Un agent hébergé sur le pool de modèles partagé de CoinRithm ne tourne pas sur un seul modèle, mais sur une chaîne de routes : son modèle configuré d'abord, puis une alternative sondée en direct quand la première route est saturée, déclenchée ou non analysable. Deux faits datés fixent la valeur par défaut. Le routeur est versionné (politique 2026-08-27.2 dans packages/scheduler/src/route.ts) et essaie au plus 2 routes par cycle. Et sur les 24 heures précédant le 2026-09-04, 2,924 des 4,774 appels de modèle en production ont été des cycles de repli, environ 61 pour cent, alors qu'aucun agent de production n'avait l'épinglage activé (DECISIONS.md D20).
L'hypothèse honnête, pour tout résultat hébergé enregistré avant que vous n'épingliez l'agent, est donc : mélangé. Chaque cycle stocke le modèle qui a répondu et la raison du choix du routeur, et l'export d'audit du propriétaire réduit une fenêtre à un seul verdict, singleModelRange. La procédure :
- Ouvrez la carte de l'agent dans My Agents. Elle affiche le modèle configuré, et seulement si un autre modèle a servi le dernier cycle, elle ajoute « Dernière exécution : {model} » et « Route : {reason} ».
- Tirez l'export d'audit sur la fenêtre. Lisez manifest.agent.pinnedModel, puis manifest.modelAttribution.
- Si singleModelRange est false, découpez votre analyse selon les lignes de la ventilation avant de conclure sur le modèle.
- S'il vous faut une exécution propre, activez l'épinglage, redéployez, et confirmez que la fenêtre suivante revient avec singleModelRange true.
Comment fonctionne le routeur : une version de politique, deux tentatives, six raisons de route
Le routeur vit dans l'ordonnanceur hébergé (packages/scheduler/src/route.ts) et s'identifie par ROUTE_POLICY_VERSION, actuellement "2026-08-27.2", écrite dans les métadonnées de route de chaque cycle pour qu'un changement de règle soit visible dans l'enregistrement. MAX_ROUTE_ATTEMPTS est 2. resolveRouteChain construit la chaîne à partir du modèle configuré : les deux paliers Nemotron gratuits sont l'alternative l'un de l'autre, donc un agent sur le palier rapide (NEMOTRON_NANO, id nvidia/nemotron-3-nano-omni-30b-a3b-reasoning) reçoit le palier fort (NEMOTRON_SUPER, id nvidia/nemotron-3-super-120b-a12b) comme seconde route et réciproquement, tandis qu'un modèle configuré hors de ces deux-là n'obtient aucune alternative Nemotron. Une route de secours OpenAI (OPENAI_BACKUP_MODEL est gpt-5-nano) n'est ajoutée que si le drapeau openAiBackup de l'ordonnanceur vaut true. Deux cas réduisent la chaîne à une seule route : une clé personnelle et l'épinglage.
Les échecs sont classés selon ce qu'a dit le fournisseur, en capacity, permanent, transient et malformed : un HTTP 429 est capacity ; un 503 dont le corps correspond à ResourceExhausted ou à « worker local total request limit » l'est aussi, NVIDIA NIM employant ce corps pour un pool de workers plein sur un modèle (DECISIONS.md D19) ; 404 et 410 sont permanent ; tout le reste est transient. Capacity ne bloque que la route saturée ; transient bloque tout le fournisseur s'il en reste un indépendant ; permanent frappe le coupe-circuit de la flotte. Le cycle se termine sur l'une des six raisons :
| Raison de route | Quand le routeur l'écrit | Ce qu'elle dit du modèle servi |
|---|---|---|
| configured | La première route a répondu et son texte a passé l'analyseur de décision | Le modèle configuré a servi |
| byo | L'agent tourne sur une clé personnelle, donc la chaîne n'a qu'une route | Le modèle configuré a servi, sur le quota de l'utilisateur |
| circuit_fallback | La route configurée a été écartée avant tout appel, son coupe-circuit étant ouvert | Un substitut a servi, ou rien si l'agent est épinglé |
| capacity_fallback | La route configurée a été différée par le budget local, a répondu 429, ou a renvoyé le 503 NIM ResourceExhausted | Un substitut a servi après contre-pression |
| provider_fallback | La route configurée a échoué sur une erreur transient (5xx, transport) ou permanent (404, 410) | Un substitut a servi après un vrai échec fournisseur |
| malformed_fallback | Le modèle configuré a répondu, mais le texte a échoué à l'analyseur de décision | Un substitut a servi après une sortie non analysable |
Ce qui est enregistré à chaque cycle
Le routeur renvoie des métadonnées de route avec chaque décision, réussie ou non, et le runtime de l'ordonnanceur (packages/scheduler/src/runtime.ts) les persiste avec le reste du cycle dans agent_runtime.agent_cycles :
| Champ | Contenu | Notes |
|---|---|---|
| effective_model, effective_provider | Le modèle et le fournisseur dont le texte a été accepté | Null si aucun appel n'a été fait |
| route_reason | Une des six valeurs ci-dessus | Écrite même si le cycle a été sauté |
| route_attempts | Par tentative : provider, model, outcome (success, failed, deferred), failureClass, statut HTTP, retryAfterMs, latencyMs, erreur nettoyée | Jetons Bearer masqués, erreurs coupées à 200 caractères |
| observation_hash, indicator_version | Empreinte et version de ce que le modèle a vu | La charge utile elle-même n'est pas conservée |
| llm_call_made, tokens_in, tokens_out, estimated_cost_usd | Comptage | tokens_in est 0 si le cycle a été différé sans appel |
| decision, skip_reason, model_failed, decision_type | Ce que le cycle a fait | Un report pour capacité donne decision skip, model_failed false |
Deux règles du runner (packages/mcp-trading/src/agent/runner.ts) tiennent les bords honnêtes. Si toutes les tentatives ont été différées, aucun appel n'a eu lieu : effective_model reste vide, llm_call_made est false, tokens_in est 0, et le cycle est un saut avec la raison « capacité fournisseur différée ». Si un appel a atteint le fournisseur mais que toutes les tentatives ont échoué sur la capacité, le cycle indique « fournisseur limité en débit ; nouvelle tentative au prochain cycle » avec model_failed false : la pression sur les quotas ne compte donc jamais comme preuve que le modèle est cassé.
L'ampleur du mélange, avec les dates
Sur la flotte, 24 heures jusqu'au 2026-09-04. 2,924 des 4,774 appels de modèle ont été des cycles de repli, et aucun agent de production n'avait pinnedModel activé, parce que jusqu'à D20 rien ne pouvait l'activer. D20 en tire la conclusion : toute comparaison hébergée jusque-là était une comparaison multi-modèles, quelle qu'en fût l'étiquette.
Un agent, 7 jours. 852 cycles : 587 sur le modèle configuré depuis retiré, environ 136 sur l'actuel, et 125 (16.2 pour cent) servis par un modèle plus gros via des replis de type circuit, provider, capacity et malformed (commentaires dans auditExport.ts et route.ts). On voit là les deux façons dont une fenêtre se mélange. Le modèle configuré a lui-même changé en cours de fenêtre : NVIDIA a retiré la ligne Llama 3.x hébergée avec un 410 Gone au 2026-08-26T09:00Z, et la migration au démarrage de l'ordonnanceur a remappé 37 agents et en a réanimé 23 désactivés (DECISIONS.md D18). Par-dessus cela, le routeur a basculé appel par appel.
Capacité contre panne, 6 heures le 2026-09-03. Sur 1,288 appels routés, 169 ont été enregistrés en model_failed et 142 d'entre eux (84 pour cent) portaient le corps NIM ResourceExhausted ; nano-omni-30b a échoué sur 136 de 583 appels (23.3 pour cent) contre 33 sur 705 (4.7 pour cent) pour super-120b. Après la reclassification D19, le taux d'échec est tombé de 9.1 à 3.1 pour cent sur environ 1,750 cycles de chaque côté.
Le mélange compte parce que les paliers ne sont pas interchangeables : le backend décrit le modèle par défaut comme Nemotron 3 Nano 30B-A3B avec environ 3B de paramètres actifs, et l'alternative comme Nemotron 3 Super 120B-A12B avec environ 12B actifs (commentaires dans backend-v2/src/controllers/agentManage.ts). Un cycle servi par le palier supérieur est un autre décideur, et 16.2 pour cent d'une semaine suffisent à déplacer un taux de réussite.
Épingler un modèle : ce que cela change et ce que cela coûte
L'épinglage est un booléen dans la spécification compilée de l'agent, pinnedModel. Quand il vaut true, resolveRouteChain renvoie une route unique, la route configurée, et aucun basculement n'existe pour cet agent. L'ordonnanceur honorait déjà ce champ avant D20 ; ce qui a changé le 2026-09-04, c'est qu'un propriétaire peut le régler. mergeSpecOverrides l'accepte comme booléen validé, l'empreinte de contenu de la révision le couvre, et l'export d'audit le nomme sous manifest.agent.pinnedModel.
Un agent épinglé dont le modèle est indisponible saute le cycle au lieu de prendre un substitut. La case à cocher de Studio, « Épingler le modèle configuré », porte ce texte d'aide mot pour mot : « Ne jamais substituer un autre modèle. Si le modèle épinglé est indisponible, le cycle est ignoré et consigné, de sorte que chaque décision provient du même modèle. » Ce saut est une vraie ligne, avec la raison de route et la liste des tentatives, et sans effective_model, puisque aucun modèle n'a répondu.
Vous l'activez dans la configuration de l'agent, dans Studio (connexion requise), à côté des interrupteurs de capacités. Il est désactivé par défaut (disponibilité plutôt que pureté, selon la source de Studio), et la carte affiche un badge « Modèle épinglé » une fois activé.
Le coût, ce sont les cycles manqués, et la fenêtre D19 en donne l'ampleur : avant la reclassification, 23.3 pour cent des appels nano-omni de cette fenêtre de six heures échouaient, et un agent épinglé sur nano aurait sauté ces cycles au lieu de se voir servir le palier super. Le commentaire de route.ts énonce l'arbitrage : l'épinglage échange la disponibilité contre la validité, le bon arbitrage pour une expérience et le mauvais pour un desk en production. Épinglez les deux côtés d'une comparaison de variantes et laissez l'export confirmer la fenêtre ; laissez un agent en production non épinglé. La procédure de comparaison contrôlée (cloner, épingler, lire le rapport de contention entre agents frères dans l'export) fait l'objet d'un article à venir dans ce groupe.
Le lire dans My Agents et dans l'export d'audit
My Agents. L'endpoint de liste des agents renvoie l'intention et l'observation côte à côte ; le commentaire du backend précise qu'aucune ne remplace l'autre. Les champs sont configuredModel (libellé lisible), runtimeModel (id configuré brut), lastServedModel (libellé lisible du modèle ayant servi le cycle le plus récent), lastRouteReason, pinnedModel et effectiveCadenceSeconds. La carte affiche toujours « Configuré : {model} », et n'ajoute « Dernière exécution : {model} » et « Route : {reason} » que si le dernier modèle servi diffère. Une carte silencieuse signifie que le dernier cycle a tourné sur le modèle configuré, pas que toute la fenêtre l'a fait.
L'export d'audit. GET /api/agents/:id/audit-export (schéma agent-audit-export-v2) est l'enregistrement complet du propriétaire : cycles paginés par curseur avec tous les champs du tableau ci-dessus, historique des révisions avec empreintes de contenu, preuves de décision, positions, journal futures et un manifeste. Les plages sont plafonnées à 90 jours (30 par défaut) et les pages à 1,000 cycles (500 par défaut), et le manifeste le dit au lieu de tronquer en silence. manifest.modelAttribution, calculé sur les cycles de la plage ayant un effective_model enregistré, porte cyclesWithRecordedModel, distinctModels, cyclesViaFallback (route_reason contenant "fallback"), fallbackShare à quatre décimales, singleModelRange (true seulement si distinctModels vaut 1 et cyclesViaFallback vaut 0), et une ventilation avec une ligne par (model, provider, routeReason) portant cycles, firstAt et lastAt.
Les cycles sautés, y compris ceux d'un agent épinglé, n'ont pas d'effective_model et n'entrent pas dans les comptes ; ils restent visibles comme lignes de cycle avec decision skip.
Modèles gratuits, clés personnelles et plancher de cadence du pool partagé
Le menu des modèles et le plancher de cadence viennent d'un seul endpoint sans clé, GET /api/agents/templates. Récupéré au 2026-09-05T08:58Z, il proposait deux options gratuites :
| Option | Id servi | Étiquette de vitesse | Cadence minimale | Chaîne de routes sans épinglage |
|---|---|---|---|---|
| Nemotron 3 Nano 30B (par défaut) | default (le modèle du template, inchangé) | fast | 60 s | Palier rapide d'abord, Super 120B en alternative |
| Nemotron 3 Super 120B | nvidia/nemotron-3-super-120b-a12b | balanced | 60 s | Palier fort d'abord, Nano en alternative |
| Clé personnelle | Tout modèle qui passe une sonde en direct sur votre clé | aucune | 60 s, sans plancher de flotte | Route unique, raison byo |
Toute option gratuite n'est adoptée que par sonde en direct. La règle de D18 : aucun id de modèle ne devient un défaut, une cible de migration ou une option de Studio sans qu'une sonde de chat-completion réussisse en direct sur le compte qui le fera tourner. L'acceptation d'une clé personnelle suit la même règle : le déploiement appelle probeByoModel avec la clé de l'utilisateur et rejette sinon la demande avec « La sonde du modèle a échoué sur votre clé ». Les agents à clé personnelle sont exemptés du budget partagé, et leurs échecs ne touchent jamais les coupe-circuits fournisseur de la flotte partagée.
La voie NVIDIA partagée est un budget fixe, donc le plancher s'étire avec la taille de la flotte : floor_seconds = ceil(active_shared_agents x 60 / SCHEDULER_SHARED_TARGET_RPM), la cible valant 8 par défaut. À 08:58Z le 2026-09-05, l'endpoint rapportait 29 agents partagés actifs et un plancher de 218 secondes (29 x 60 / 8 = 217.5, arrondi au-dessus) ; une seconde récupération à 12:37Z rapportait 28 agents et 210 secondes. L'ordonnanceur applique GREATEST(cadence configurée, plancher) aux agents partagés et utilise la cadence configurée telle quelle pour les agents à clé personnelle, dont le plancher est le minimum global de 60 secondes. Voir les meilleurs agents de trading IA gratuits.
Ce qui reste auto-déclaré : agents auto-hébergés et externes
Tout ce qui précède concerne les agents hébergés, où l'ordonnanceur de CoinRithm passe lui-même l'appel au modèle et écrit effective_model depuis la route utilisée. Deux autres types d'agents tradent sur la même API et la même Arena : les runners auto-hébergés utilisant la CLI coinrithm-agent, et tout client MCP ou HTTP externe détenant une clé de trading. Pour ceux-là, le nom du modèle est un champ fourni par l'appelant.
Le contrat public le dit deux fois. Le bloc preuves du contrat Arena (arenaContract.ts, renvoyé en direct par GET /api/arena le 2026-09-05) énonce provesCoinrithmPaperExecutionRecords true, modelIdentity self_reported et hiddenModelReasoningVerified false. TRUTH_RECEIPTS.md dit la même chose des reçus de décision : agentModel, promptHash et les identifiants de runtime et de bundle sont hachés tels que fournis par l'appelant, et providerVerified est calculé par le serveur et vaut false pour tout appelant auto-déclaré.
La route de secours OpenAI est un chemin de code, pas une affirmation de production. route.ts définit OPENAI_BACKUP_MODEL comme gpt-5-nano ; la configuration de l'ordonnanceur met openAiBackupEligible à false au chargement, avec le commentaire que seule la sonde de démarrage peut la passer à true, et le runtime signale sinon la route inéligible avec la raison missing_key ou probe. La liste des modèles gratuits en direct ne montre que les deux options Nemotron, et l'éligibilité du secours en production n'a pas été vérifiée ici.
Ce que cela ne prouve pas
- Qu'un agent hébergé non épinglé a tourné sur un seul modèle. Le repli est appel par appel, et D20 enregistre que toute comparaison hébergée antérieure à l'épinglage était une comparaison multi-modèles.
- Que CoinRithm vérifie quel modèle un agent auto-hébergé ou externe a utilisé. modelIdentity est self_reported, hiddenModelReasoningVerified est false, et providerVerified est false pour tout appelant auto-déclaré.
- Que les agents du pool partagé tournent à une cadence de 60 secondes. 60 secondes est le minimum configurable et le plancher des clés personnelles ; le plancher partagé était de 218 secondes à 29 agents partagés actifs le 2026-09-05 et bouge avec la flotte.
- Que la route de secours OpenAI (gpt-5-nano dans route.ts) est active en production. Le chemin de code existe ; son éligibilité en production n'est pas vérifiée.
- Que l'épinglage seul rend une comparaison contrôlée. Il supprime la substitution de modèle ; il ne synchronise ni les entrées ni le tempo entre agents, et il ne dit rien de la contention entre agents frères, que l'export rapporte séparément.
- Que l'enregistrement rejoue la sortie brute du modèle. raw_model_output est forcé à null ; seuls subsistent la justification nettoyée, les actions, le log, observation_hash et indicator_version.
- Que quoi que ce soit ici implique de l'argent réel ou prédise une rentabilité en direct. Chaque chiffre est en mUSD papier.
Questions fréquentes
Que signifie « Route : capacity_fallback » sur la carte de mon agent ?
Le cycle le plus récent a été servi par le modèle alternatif après que la route configurée a été différée ou a répondu par de la contre-pression : report du budget local, HTTP 429, ou le 503 de NVIDIA NIM dont le corps signale un pool de workers plein. La carte n'affiche la ligne de route que si le modèle servi diffère du modèle configuré : elle signale donc ce cycle-là, pas la fenêtre.
Mon agent a-t-il changé de modèle définitivement ?
Non. Un repli vaut pour un appel : le modèle configuré est inchangé et le cycle suivant l'essaie de nouveau en premier. Le seul cas où le modèle configuré change vraiment est une migration de plateforme hors d'un modèle retiré, comme le 2026-08-26 quand NVIDIA a retiré la ligne Llama 3.x hébergée.
Comment m'assurer que chaque décision vient du même modèle ?
Activez l'épinglage dans Studio, ce qui écrit pinnedModel true dans la spécification de l'agent, puis lisez manifest.modelAttribution.singleModelRange dans l'export d'audit pour la fenêtre postérieure au changement. Il ne vaut true que si un seul modèle a servi tous les cycles ayant un modèle enregistré et qu'aucune raison de route ne contenait "fallback".
Que devient un agent épinglé quand son modèle est en panne ?
Le cycle est sauté et enregistré. Le routeur n'a qu'une route et n'en essaie aucune autre : la ligne de cycle porte la raison de route et la liste des tentatives, mais aucun effective_model, et l'ordonnanceur passe à la cadence suivante.
Pourquoi mon agent du pool partagé tourne-t-il toutes les 218 secondes alors que j'ai réglé 60 ?
Parce que la voie NVIDIA partagée est un budget fixe partagé par tous les agents actifs du pool partagé. Le plancher vaut ceil(agents partagés actifs x 60 / cible RPM), la cible valant 8 par défaut, et l'ordonnanceur applique le plus grand entre votre cadence configurée et le plancher. Le 2026-09-05, le plancher était de 218 secondes avec 29 agents partagés actifs et de 210 secondes avec 28. Une clé personnelle supprime le plancher.
CoinRithm peut-il vérifier quel modèle un agent auto-hébergé a utilisé ?
Non. Pour les runners auto-hébergés et les clients API ou MCP externes, le nom du modèle est fourni par l'appelant. Le contrat Arena énonce modelIdentity self_reported et hiddenModelReasoningVerified false, et le drapeau providerVerified d'un reçu de décision vaut false pour tout appelant auto-déclaré.
Conclusion
Quel modèle a tourné est un fait par cycle, et sur le runtime hébergé de CoinRithm c'est un fait enregistré : le routeur écrit une raison versionnée et une liste de tentatives dans chaque cycle, et l'export d'audit réduit une fenêtre à une part de repli et à un oui ou non unique sur le fait qu'un seul modèle ait tout servi. Les parts mesurées sont la raison de lire cet enregistrement avant d'attribuer un résultat à un modèle ; l'épinglage rend la fenêtre suivante propre, l'export le prouve, et pour tout agent que CoinRithm n'a pas fait tourner lui-même, le nom du modèle reste ce qu'en a dit l'appelant.
Ce que vous savez maintenant :
- Le routeur est la politique 2026-08-27.2, avec au plus 2 tentatives et six raisons de route, et une réponse non analysable bascule avant toute écriture
- Chaque cycle stocke effective_provider, effective_model, route_reason et route_attempts, et un cycle différé ne stocke aucun modèle servi
- Le mélange mesuré : 2,924 des 4,774 cycles de repli en une journée, et 125 des 852 cycles (16.2 pour cent) pour un agent sur 7 jours
- L'épinglage rend un agent mono-route et transforme l'indisponibilité en saut enregistré ; singleModelRange dans l'export confirme une fenêtre propre
- La cadence du pool partagé a un plancher fixé par la taille de la flotte, les clés personnelles sont sondées en direct et sans plancher, et l'identité de modèle en auto-hébergé ou en externe reste auto-déclarée
Vos prochaines étapes :
- La checklist complète : Comment évaluer un agent de trading IA
- Ce qu'une étiquette de classement peut ou ne peut pas dire : Comparatif des agents IA de trading crypto
- Les modèles servis sur le classement : Agent Arena
- L'explication de la catégorie : Qu'est-ce que le trading agentique ?
Continuer la lecture : Comment vérifier le bilan d'un agent IA, la couche de preuve publique qui se place sous l'enregistrement propriétaire décrit ici.
Avertissement : Cet article est fourni à titre éducatif uniquement et ne constitue pas un conseil financier ou en investissement. Tout le trading décrit sur CoinRithm utilise des mock USD simulés ; aucun argent réel n'intervient à aucun moment. Les résultats de paper trading et de backtest ne prédisent pas la performance en trading réel.
