Claude Fable AIOS : Un Second Cerveau sur le Modèle le Plus Cher

Claude Fable AIOS : Un Second Cerveau sur le Modèle le Plus Cher

Le chiffre qui a recadré tout le projet était 50 $.

Cinquante dollars par million de tokens de sortie. C'est ce que coûte Claude Fable 5 sur l'API — le double d'Opus 4.8, et le modèle en disponibilité générale le plus cher qu'Anthropic ait jamais lancé (10 $ par million en entrée, 50 $ par million en sortie, confirmé lors du lancement du 9 juin). Je prévoyais de diriger un AIOS personnel fraîchement construit — un système d'exploitation IA, un second cerveau avec des mains — vers ce modèle et le laisser gérer ma vie. Puis j'ai fait le calcul sur une serviette pour un seul briefing matinal qui lit mon calendrier, trois canaux Slack, les charges Stripe de la veille et mon tableau de tâches, puis rédige un résumé de 600 mots. Sur Fable, en exécutant ça chaque matin, les tokens de sortie seuls coûteraient plus que mes abonnements Spotify, Netflix et iCloud réunis. Pour un paragraphe que je lis en quatre-vingt-dix secondes.

C'est ce que personne ne vous dit sur la construction d'un Claude Fable AIOS. Le framework pour un second cerveau est la partie facile. La partie difficile — celle qui détermine réellement si votre système survit au contact d'une facture — c'est de décider ce qui vaut la peine d'être exécuté sur le modèle le plus intelligent et le plus cher dont vous disposez, et ce qui devrait être discrètement confié à quelque chose de moins cher. J'ai appris cela de la manière coûteuse, et l'une des leçons impliquait un email qui n'aurait jamais dû être envoyé.

Laissez-moi vous expliquer ce que j'ai construit, le framework des Quatre C sur lequel je l'ai bâti, et les décisions de coûts qui ont transformé un jouet intéressant en quelque chose à qui je confie réellement mon entreprise.

Ce Qu'un Claude Fable AIOS Est Vraiment (et Pourquoi Fable Change les Calculs)

Un second cerveau, c'est votre savoir — notes, décisions, archives, les choses dont la disparition vous empêcherait de dormir. Un AIOS est l'infrastructure au-dessus : les compétences, les connexions de données en direct, les automatisations qui agissent sur ce savoir sans que vous soyez dans la boucle. Le cerveau stocke. Le système d'exploitation agit.

J'ai déjà construit un AIOS personnel sur Claude Code, et cette version tournait sur des modèles bon marché et rapides où l'on pouvait se permettre d'être négligent. Brûler quelques milliers de tokens sur une requête jetable ? Qui s'en soucie. Tout le calcul change quand votre moteur de raisonnement est Claude Fable 5.

Voici pourquoi Fable exige spécifiquement une meilleure architecture. Fable est la tranche publique d'Anthropic de la lignée Mythos 5 — la même famille que j'ai disséquée quand Fable 5 et Mythos 5 ont été lancés. Il est véritablement excellent en raisonnement à long terme, en synthèse multi-fichiers, et dans le type de décisions de jugement où les modèles moins chers échouent. Mais il facture à un tarif qui punit le gaspillage. Et la situation d'abonnement rend cela plus tranchant, pas plus doux :

• Fable était gratuit sur Pro et Max du 9 au 22 juin 2026. Le 23 juin, Anthropic l'a retiré des limites du plan — l'utilisation continue consomme des crédits d'utilisation aux tarifs API (selon le déploiement d'Anthropic).
• Dans la fenêtre d'abonnement, Fable comptait environ le double d'Opus pour vos limites. Sur le plan Max à 200 $/mois avec ses fenêtres de session d'environ 5 heures, une utilisation intensive de Fable pouvait épuiser votre allocation hebdomadaire en quelques jours, après quoi le sélecteur de modèle vous rétrograde silencieusement vers Sonnet.

Vous obtenez donc une courte lune de miel où Fable semble gratuit, suivie d'un mur dur où chaque token porte un signe dollar. Si vous concevez votre AIOS pendant la lune de miel en supposant Fable partout, vous recevrez une facture brutale au moment où la fenêtre se ferme. Le système doit être conçu pour la réalité post-23 juin dès le premier jour.

Cette unique contrainte — le modèle le plus intelligent est trop cher pour tout — finit par façonner chaque autre décision. Gardez-la en tête, car c'est le fil rouge à travers les quatre C.

Les Quatre C : L'Architecture qui Survit à une Facture

J'organise tout le système autour de quatre couches, construites dans un ordre strict : Contexte, Connexions, Capacités, Cadence. Vous ne pouvez pas sauter d'étape. Cadence sans Capacités est un cron job qui tire dans le vide. Capacités sans Connexions est un carnet astucieux. Connexions sans Contexte est un agent agissant pour le compte d'un inconnu.

Ce qui suit n'est pas la version générique de ce framework. C'est la version qui suppose que votre modèle de raisonnement coûte 50 $ par million de tokens de sortie — parce que cette hypothèse change ce à quoi chaque couche devrait réellement ressembler.

J'ai nommé mon build « Herk 2 » — la deuxième itération d'un projet au long cours pour mettre l'ensemble de mes connaissances personnelles et professionnelles dans un système qui pense avec moi au lieu de simplement stocker ce que j'ai déjà pensé. Le nom n'a pas d'importance. L'ordre, si.

Contexte : Du Markdown Brut, Parce que les Tokens Sont Désormais de l'Argent

Le Contexte est la couche statique — tout ce que le système sait de moi et qui ne change pas d'une minute à l'autre. Objectifs. Modèle économique. Liste de clients. Voix de marque. Processus. L'archive des décisions que j'ai déjà prises pour ne pas les re-débattre.

Tout vit dans des fichiers markdown dans un seul dépôt ancré par un CLAUDE.md à la racine. Pas de base de données. Pas de vector store. Des fichiers texte bruts dans des dossiers que je peux lire de mes propres yeux.

Les gens supposent qu'il faut un système de récupération sophistiqué pour une base de connaissances. À l'échelle personnelle et en début d'activité, non — et sur Fable, le mauvais choix est activement coûteux. Un système de fichiers bien organisé gère une base de connaissances étonnamment grande sans aucune base de données. Le CLAUDE.md agit comme un arbre de routage : il ne contient pas le savoir, il contient la carte vers le savoir, indiquant à l'agent quel fichier ouvrir pour quelle question.

herk2/
├── CLAUDE.md                    # l'arbre de routage — pointe vers tout
├── context/
│   ├── business.md              # modèle, offres, tarifs, positionnement
│   ├── clients.md               # comptes principaux, statut, historique
│   ├── goals.md                 # trimestriels + annuels, avec le pourquoi
│   ├── voice.md                 # comment j'écris, ce que je ne dis jamais
│   ├── decisions/               # un fichier par décision majeure, daté
│   └── archives/                # projets terminés, post-mortems
├── connections/                 # wrappers d'API, clés à portée limitée
├── skills/                      # capacités nommées, un dossier chacune
└── automations/                 # cadence — déclencheurs et planifications

Pourquoi est-ce important pour les coûts ? Parce que l'arbre de routage signifie que Fable ne charge que le seul fichier pertinent pour la tâche au lieu de fourrer toute la base de connaissances dans le contexte. Quand l'entrée coûte 10 $ par million de tokens, charger 40 fichiers markdown inutiles à chaque requête, c'est de l'argent réel. Le routeur garde chaque appel léger.

Il y a aussi un avantage plus discret. Le markdown brut est agnostique au modèle. Exactement le même dossier context/ fonctionne que l'agent qui le lit soit Fable, Sonnet ou un modèle non-Anthropic comme Codex. Je ne suis pas verrouillé. Si un modèle moins cher devient assez bon le trimestre prochain, j'échange le moteur et je garde le cerveau. Essayez de faire ça avec un schéma de base de données propriétaire câblé aux embeddings d'un seul fournisseur.

Pour remplir tout cela sans procrastiner trois semaines, j'utilise une compétence d'interview — j'y reviendrai dans la section Capacités, car c'est le meilleur truc que j'ai trouvé pour construire du contexte rapidement. Pour l'instant, retenez juste ceci : le contexte est la fondation, il vit en markdown, et l'arbre de routage est ce qui empêche votre facture Fable d'exploser.

Connexions : Les Clés API Sont Votre Vraie Couche de Permissions

Une fois que le système sait qui je suis, il doit atteindre le monde en direct. Les Connexions sont la couche dynamique — des API vers Stripe, QuickBooks, Google Workspace, ClickUp, Slack. C'est ce qui permet à l'AIOS de lire le chiffre d'affaires d'aujourd'hui, le calendrier de ce matin, les fils vraiment non lus, plutôt que de raisonner sur un instantané obsolète.

Voici la leçon qui m'a coûté le plus cher, et elle n'a rien à voir avec les tokens.

J'avais un agent dont le travail était de trier ma boîte de réception et de rédiger des brouillons de réponses pour ma révision. Les instructions étaient explicites : brouillon seulement, jamais envoyer, toujours me montrer d'abord. Un matin, il a mal interprété une instruction en plusieurs étapes — il a lu « envoie le suivi à la liste dont nous avons discuté » comme une instruction d'envoyer réellement, à une vraie liste. Il a envoyé. À de vraies personnes. Un email qui n'était absolument pas prêt.

Je l'ai rattrapé vite et les dégâts étaient mineurs — un embarrassant « veuillez ignorer » de suivi. Mais la leçon était permanente : un prompt n'est pas un système de permissions. Dire à un agent « n'envoie pas d'emails » est une suggestion. C'est une chaîne de texte que le modèle peut mal lire, de la même façon que je peux mal lire un panneau de signalisation la nuit. La vraie confiance vient du fait que l'agent n'a physiquement pas la capacité de faire ce que vous ne voulez pas qu'il fasse.

Alors maintenant chaque connexion est gouvernée par la portée de sa clé API, pas par la politesse de mes prompts. L'agent de tri d'emails détient une clé avec des permissions de lecture et de brouillon et rien d'autre. Il ne peut pas envoyer, parce que l'identifiant qu'il a reçu ne porte pas cette portée. S'il interprète mal une instruction, le pire cas est un brouillon dans mon dossier. La couche de permissions vit au niveau de la clé, là où le modèle ne peut pas discuter.

# FAUX — permission comme suggestion sur laquelle le modèle peut trébucher
SYSTEM : Vous pouvez lire et rédiger des emails. Jamais envoyer. Toujours confirmer d'abord.

# JUSTE — permission comme limite dure sur l'identifiant
GMAIL_KEY scope: gmail.readonly, gmail.compose   # pas de gmail.send. Jamais.

Limitez la portée de chaque clé au minimum requis par la tâche. Lecture seule quand la lecture seule suffit. Brouillon, pas envoi. Accès à un seul projet, pas à tout le compte. C'est fastidieux à mettre en place et c'est le travail de sécurité le plus important de tout le système — surtout parce que les modèles d'Anthropic sont à code fermé, vous confiez donc une boîte noire avec l'accès à votre entreprise. Plus la clé est étroite, plus le rayon de dégâts est petit quand quelque chose tourne mal. Et quelque chose tournera mal. Dans mon cas, il a envoyé un email. Dans le vôtre, ce sera autre chose.

Cette erreur a aussi reformulé ma façon de penser la couche suivante. Car plus vos compétences deviennent capables, plus il importe ce qu'elles sont autorisées à toucher.

Capacités : Compétences, Sous-Agents et l'Art de Ne Pas Utiliser Fable

Les Capacités sont les verbes du système — les compétences nommées, agents et automatisations qui font réellement des choses. Chacune est un dossier avec un SKILL.md définissant ce qu'elle fait et quand elle se charge. Elles vont d'un prompt d'un paragraphe (« résume cette transcription dans ma voix ») à un flux de travail en plusieurs étapes qui recherche, rédige, révise et publie.

La leçon d'architecture ici est venue en observant mes compétences se dégrader à mesure qu'elles grossissaient. Un seul agent essayant de rechercher et rédiger et polir dans une longue session souffre de dérive de contexte — au moment où il polit, il a à moitié oublié le brief de recherche, et la sortie dérive. La solution est la modularité : des sous-agents séparés dans des sessions séparées, chacun avec une tâche. Un agent recherche et transmet un brief propre. Un agent frais rédige à partir de ce brief sans le fouillis de recherche dans son contexte. Un troisième polit. Des transmissions propres, pas de dérive. J'ai appris ce modèle à la dure, la même leçon que je réapprends sans cesse avec les flux de travail d'agents multi-sessions.

Mais la décision qui compte vraiment pour un Fable AIOS est quel modèle fait tourner chaque sous-agent. Et la réponse, la plupart du temps, est pas Fable.

C'est le cœur de tout. La délégation n'est pas seulement un modèle de qualité — sur Fable, c'est un modèle de survie. Fable est un stratège senior dont le taux horaire est brutal. Vous ne mettez pas votre personne la plus chère à faire de la saisie de données. Donc je délègue agressivement :

• Fable gère le travail véritablement difficile, irréversible et à haut jugement : la synthèse finale, l'appel stratégique, ce dont l'erreur coûte cher. Les 10 % du travail qui justifient 50 $ par million de tokens.
• Sonnet gère la majeure partie du travail réel : rédaction, résumés, transformation de données, le travail de routine parallèle. C'est une fraction du coût et suffisamment bon pour 80 % des tâches.
• Haiku gère le trivial et à haut volume : classification, extraction, recherches rapides, les choses que vous exécuteriez des centaines de fois.

Le modèle qui fait fonctionner tout cela est disperser, puis agréger. Quand une tâche a des parties parallèles indépendantes — disons, « résume ces huit fils de clients » — je ne donne pas les huit à Fable. Je les disperse vers huit workers bon marché Haiku ou Sonnet tournant en parallèle, chacun produisant un résumé concis. Alors seulement, et uniquement alors, Fable reçoit les huit résumés agrégés et fait la seule chose pour laquelle il vaut la peine de payer : le jugement transversal. « Le client trois et le client sept sont tous deux discrètement mécontents du même retard de livraison — voici le schéma, voici ce que je ferais. » Cette perspicacité vaut 50 $ par million de tokens. Lire huit fils bruts pour la produire, non.

La différence de coûts n'est pas marginale. La sortie de Fable est le double d'Opus et plusieurs fois celle de Sonnet. Pousser les 80 % routiniers du travail vers des workers moins chers et réserver Fable pour les 20 % irremplaçables, c'est la différence entre un AIOS que vous pouvez vous permettre de faire tourner quotidiennement et un que vous éteignez après la première facture.

Si vous ne construisez qu'une chose de ce post, construisez ceci : une compétence « Grill Me ». Elle vous interview sans relâche, posant question après question pour extraire des connaissances que vous ne vous assiériez jamais pour écrire. « Quel est votre taux horaire ? Pourquoi ce montant ? Quel client licencieriez-vous si vous pouviez ? À quoi ressemble vraiment une bonne semaine ? » Chaque réponse est écrite dans le bon fichier de contexte en markdown structuré. Cela transforme votre bavardage en une base de connaissances remplie — et le meilleur, c'est que vous pouvez faire tourner l'intervieweur sur le Sonnet bon marché, car poser de bonnes questions ne nécessite pas un modèle frontier. (Il existe une compétence complète construite autour de ce modèle d'interview si vous voulez prendre de l'avance.)

Si vous préférez ne pas assembler cette couche de délégation vous-même, c'est exactement le type de système que je construis pour mes clients — vous pouvez voir ce que j'accepte ici. Mais honnêtement, le framework ci-dessus suffit pour commencer seul ce week-end.

Une dernière leçon sur les capacités qui m'a sauvé à répétition : vérifiez les sorties, ne leur faites pas confiance aveuglément. Quand une compétence construit quelque chose de visuel ou fonctionnel — un rapport, un tableau de bord, une page générée — je la fais réellement s'exécuter et vérifier le résultat, pas juste déclarer le succès. Un agent qui dit « terminé ! » n'est pas la même chose que quelque chose qui fonctionne. Les tests dynamiques et fonctionnels des sorties d'IA sont non négociables dès que le système agit de manière autonome.

Ce qui nous amène à la couche où il agit entièrement de manière autonome.

Cadence : Quand le Système Tourne Sans Vous

La Cadence, c'est quand les choses se déclenchent. Trois types de déclencheurs : planifiés (chaque matin à 6 h), basés sur des événements (une nouvelle charge Stripe, un push GitHub, un email entrant), et manuels (je tape /plan-quotidien). La Cadence est ce qui transforme un assistant intelligent en un système d'exploitation qui travaille pendant que je dors.

C'est aussi là où coûts, sécurité et maintenance entrent en collision simultanément. Une compétence que vous déclenchez manuellement s'exécute quand vous le choisissez, sous vos yeux. Une compétence sur une cadence s'exécute que vous regardiez ou non — ce qui signifie qu'une automatisation alimentée par Fable qui se déclenche toutes les heures est une facture Fable qui s'accumule toutes les heures, pour toujours, même les jours où elle ne produit rien d'utile.

Mes règles de cadence sont donc strictes :

1. Les tâches planifiées sur Fable sont rares et uniquement pour les tâches à haute valeur. Le briefing stratégique matinal, oui — une fois par jour, et même là, la collecte est faite par des workers bon marché et seule la synthèse finale touche Fable. Tout ce qui est routinier tourne sur Sonnet ou Haiku selon la planification.
2. Chaque automatisation est surveillée. L'autonomie ne supprime pas le besoin de supervision humaine — elle augmente les enjeux de ne pas en avoir. Je journalise chaque exécution automatisée et parcours les logs. L'envoi massif d'email m'a appris qu'un agent agissant sans supervision sur un planning est exactement la façon dont de petites mauvaises interprétations deviennent des événements réels.
3. Plafonds de coûts par automatisation. Chaque tâche planifiée a un budget approximatif de tokens. Si une exécution le dépasse, c'est un signal que la compétence a dérivé ou que l'entrée a gonflé, et c'est signalé.

C'est la même discipline que j'applique aux automatisations planifiées de Claude en général — mais Fable rend la ligne des coûts de ce grand livre impossible à ignorer. Sur un modèle bon marché, un cron emballé est ennuyeux. Sur Fable, c'est une surprise à quatre chiffres.

Construisez les quatre C dans l'ordre et vous obtenez quelque chose de véritablement différent d'un chatbot : un système qui conserve votre contexte, atteint vos vrais outils via des clés à portée limitée, expose ses compétences comme des capacités nommées, et les exécute selon une cadence que vous contrôlez — la plupart sur des modèles bon marché, avec Fable réservé aux moments qui ont véritablement besoin d'un cerveau frontier.

À Quoi Ça Ressemble Quand Ça Marche

Je veux être précis sur le résultat, parce que « second cerveau » est une expression qui a été vidée de son sang par des gens qui vendent des templates Notion.

Deux démos m'ont convaincu que le système était réel. La première : je l'ai pointé vers une longue chaîne YouTube et j'ai demandé une analyse structurée de la stratégie de contenu du créateur. Il a extrait les transcriptions, dispersé les résumés vers des workers bon marché, et remis à Fable l'agrégat — qui a produit une lecture véritablement perspicace du positionnement et des lacunes de la chaîne, en un seul prompt. Le travail de fond était bon marché ; seul l'insight était cher.

La seconde était plus utile au quotidien : une carte interactive des relations entre mes propres outils, flux de travail et projets, générée depuis mon dossier de contexte en un prompt — quelle automatisation alimente quel projet, quelle compétence dépend de quelle connexion. Voir mon propre système sous forme de graphe a révélé deux dépendances dont j'avais oublié l'existence.

Les résultats réalistes, énoncés honnêtement sans chiffres inventés :

• Les coûts de récupération de contexte ont chuté significativement une fois que l'arbre de routage a remplacé « tout charger ». Les tokens d'entrée sont la moitié bon marché de Fable, mais charger 40 fichiers inutiles à chaque appel s'additionnait quand même — le routeur a réduit cela aux un ou deux fichiers dont une tâche a réellement besoin.
• Le modèle de délégation est là où se trouvent les vraies économies. Déplacer les ~80 % routiniers du travail hors de Fable vers Sonnet et Haiku est le seul changement qui a rendu l'opération quotidienne abordable. Votre résultat dépend de votre mix de tâches, mais la direction n'est pas subtile — une sortie frontier à 50 $ par million de tokens est quelque chose que l'on rationne, pas quelque chose que l'on gaspille.
• La partie chère est maintenant mon attention, pas l'API. La maintenance est le vrai coût continu. Les connexions cassent. Les API changent. Les compétences dérivent. Un système aussi capable est un système que vous entretenez, pas un que vous configurez et oubliez.

Si vous évaluez si cela vaut votre temps, ce dernier point est le piège honnête. Parlons donc des parties qui ne sont pas dans le reel de highlights.

La Vérité Sans Filtre : Ce Que Ça Vous Coûte et Qui N'apparaît Pas sur la Facture

La facture de tokens est le coût sur lequel les gens se fixent. Ce n'est pas celui qui va vous attraper.

Le plus grand défi, ce sont les personnes, pas les modèles. Construire un AIOS personnel est difficile mais faisable — vous contrôlez chaque variable. Au moment où vous essayez de l'étendre à une équipe, la difficulté se multiplie. Gestion des connaissances partagées, amener les collègues à réellement maintenir leur contexte, former les gens à penser en compétences et délégation plutôt qu'en prompts uniques — c'est du changement organisationnel, et aucun modèle ne le résout. Si vous êtes un opérateur solo, vous avez un avantage énorme et sous-estimé ici : il n'y a personne à convaincre sauf vous-même.

Le code fermé signifie confier une boîte noire à votre entreprise. Anthropic n'ouvre pas le modèle. Vous routez de vraies données de revenus, de vraies informations clients, de vrais calendriers à travers une infrastructure que vous ne pouvez pas inspecter. C'est pourquoi la couche de permissions avec des clés à portée limitée n'est pas de la paranoïa optionnelle — c'est le seul vrai contrôle que vous avez. Traitez les données sensibles délibérément : ce qui doit véritablement circuler vers le modèle, et ce qui peut rester dans des fichiers que l'agent lit localement sans aller-retour vers une API.

L'architecture ne survivra pas au contact avec la réalité sans changements. La mienne a déjà été reconstruite une fois — c'est pourquoi c'est « Herk 2 ». Vous rencontrerez des problèmes de latence, des surprises de consommation de tokens, une compétence qui fonctionnait très bien jusqu'à ce que votre base de connaissances triple de taille. Le système évolue en fonction de ce qui casse réellement, pas de ce que vous aviez planifié. Construisez-le en vous attendant à le refactoriser.

N'externalisez pas votre réflexion — associez-vous avec elle. L'utilisation de plus haute valeur que j'ai trouvée n'est pas du tout de l'automatisation. C'est utiliser le système comme un partenaire de réflexion : lancer plusieurs sous-agents pour débattre d'une décision sous différents angles, puis lire l'argument. L'AIOS qui gère votre travail routinier est utile. Celui qui aiguise votre jugement est celui qui vaut la peine d'être construit.

Voici la prédiction à laquelle je m'engage : les personnes qui gagneront avec des modèles frontier comme Fable ne seront pas celles qui les utilisent le plus. Ce seront celles qui les utilisent le moins — celles qui ont construit des systèmes suffisamment disciplinés pour dépenser 50 $-par-million-de-tokens uniquement sur la poignée de décisions qui méritent véritablement un cerveau frontier, et router tout le reste vers des workers qui coûtent un dixième. La retenue est la compétence. Le modèle n'est que le moteur.

La Seule Chose à Faire Cette Semaine

Revenez au tout premier chiffre de ce post — les 50 $. Puis regardez n'importe quel flux de travail IA que vous exécutez en ce moment et posez-vous la question qui a recadré tout mon projet : qu'est-ce qui ici a réellement besoin du modèle le plus intelligent et le plus cher, et pour quoi est-ce que je surpaye ?

Vous n'avez pas besoin de Fable pour commencer. Vous n'avez pas besoin de construire les quatre C ce week-end. Commencez par le Contexte : ouvrez un dossier, créez un CLAUDE.md, écrivez en markdown brut qui vous êtes et ce que fait votre entreprise. Ce seul fichier — la fondation sur laquelle tout le reste repose — ne coûte rien et fonctionne avec chaque modèle que vous échangerez jamais.

Le second cerveau stocke ce que vous savez déjà. L'AIOS agit dessus. Mais la discipline qui détermine si le vôtre est abordable ou abandonné est la seule chose qu'aucun modèle ne construira pour vous : savoir exactement ce qui mérite qu'on y réfléchisse en profondeur, et ce qui ne le mérite pas.

Alors — si vous exécutiez cet audit sur votre propre stack ce soir, que trouveriez-vous que vous avez payé au tarif d'un stratège ?

Questions Fréquemment Posées

Qu'est-ce qu'un Claude Fable AIOS ?

Un Claude Fable AIOS est un système d'exploitation personnel d'IA qui utilise Claude Fable 5 comme moteur de raisonnement pour agir sur votre base de connaissances. Il combine un « second cerveau » en markdown avec des connexions API en direct, des compétences nommées et des automatisations planifiées — construit sur le framework des Quatre C : Contexte, Connexions, Capacités et Cadence.

Combien coûte l'exécution d'un AIOS sur Claude Fable 5 ?

Claude Fable 5 coûte 10 $ par million de tokens d'entrée et 50 $ par million de tokens de sortie — le double d'Opus 4.8 et le modèle Anthropic de disponibilité générale le plus cher. Faire tourner un AIOS entier sur Fable est impraticable ; l'approche abordable délègue le travail routinier à des workers Sonnet et Haiku moins chers et réserve Fable pour la synthèse à haut jugement. Voir la section Capacités ci-dessus.

Quels sont les Quatre C d'un système d'exploitation IA ?

Les Quatre C sont Contexte (connaissances statiques en markdown), Connexions (intégrations API en direct), Capacités (compétences et agents nommés) et Cadence (automatisations planifiées et basées sur des événements). Ils se construisent dans un ordre strict — chaque couche dépend de la précédente, comme expliqué dans la section architecture ci-dessus.

Pourquoi utiliser des portées de clés API plutôt que des instructions de prompt pour la sécurité IA ?

Parce qu'un prompt est une suggestion que le modèle peut mal interpréter, tandis qu'une portée de clé API est une limite dure qu'il ne peut physiquement pas franchir. Après qu'un agent ait accidentellement envoyé un vrai email malgré les instructions « ne jamais envoyer », j'ai déplacé toutes les permissions vers des identifiants à portée limitée — l'agent email a maintenant une clé sans accès d'envoi, de sorte qu'une mauvaise interprétation d'instruction ne peut pas causer de dommage.

Puis-je changer de modèle sans reconstruire mon AIOS ?

Oui — si votre contexte vit dans des fichiers markdown bruts plutôt que dans une base de données propriétaire. Puisque la couche de connaissances est du texte agnostique au modèle, vous pouvez échanger Claude Fable contre Sonnet, Opus ou même un modèle non-Anthropic comme Codex sans reconstruire le système. Seul le moteur de raisonnement change ; le cerveau reste.

Travaillons Ensemble

Vous cherchez à construire des systèmes d'IA, automatiser des flux de travail ou faire évoluer votre infrastructure technologique ? J'adorerais vous aider.

• Fiverr (projets sur mesure et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io