Depuis la sortie de Kimi K3, la même plainte revient partout : le quota fond en quelques heures. Des devs basculent tout leur workflow sur K3, se prennent le mur au bout de trois jours, et concluent que le modèle est trop cher pour un usage sérieux.
Chez Ulycorp, on tourne toute la journée sur K3 en mode max, sur nos projets internes comme sur ceux de nos clients, et on ne dépasse pas notre budget journalier — qu'on s'est fixé à 3,22 % du quota mensuel, soit très exactement de quoi tenir 31 jours sans jamais être en excès. On y arrive presque tous les jours sans y penser.
Ce n'est pas une astuce de quota. C'est une décision d'architecture, et elle tient en une phrase :
L'orchestrateur ne code pas.
La config se construit après l'audit, jamais avant
Sur chaque nouveau projet — ou chaque projet repris en cours de route — on commence par une revue complète de la codebase avant d'écrire la moindre ligne de configuration. L'objectif est de répondre à une seule question : de quoi ce projet a-t-il réellement besoin en termes de développement ?
De cette revue sort une liste : les agents et sous-agents nécessaires, les MCP à brancher, les skills à charger, les tools à autoriser. C'est cette liste qui détermine la configuration, et elle change à chaque projet. Ce qui ne change jamais, en revanche, c'est la logique de répartition des rôles décrite ci-dessous. Un projet = une config spécifique, une architecture identique.
Toute cette configuration — agents, permissions, routage des modèles — est construite et maintenue sous OpenCode. C'est le socle qui nous permet de définir, projet par projet, qui a le droit de coder, qui n'a que la lecture, et quel modèle répond derrière chaque agent.
La documentation officielle détaille cette configuration. Kimi documente d'ailleurs directement l'intégration, côté Kimi Code comme côté Kimi Open Platform.
L'architecture : quatre rôles, une seule règle
K3 occupe le poste d'orchestrateur, et ses permissions sont volontairement amputées : il peut lire des fichiers, analyser, planifier et dispatcher des tâches. Il ne peut pas écrire de code.
C'est tout le levier. Un modèle de raisonnement qui code génère du diff, réécrit des fichiers entiers, itère sur ses propres sorties, relit le résultat, recommence. C'est là que partent les tokens. Le même modèle en position d'orchestration lit du contexte, raisonne, et produit des instructions — quelques centaines de tokens de sortie là où une session de codage en consomme des dizaines de milliers.
Concrètement : on parle à l'orchestrateur, en langage naturel. Il comprend la demande, la décompose, décide qui fait quoi, et envoie lui-même les prompts aux agents concernés. On ne s'adresse jamais directement aux agents d'exécution.
Ce sont eux qui écrivent le code. Chaque agent est assigné à un modèle en fonction de la difficulté réelle de sa zone de responsabilité :
- —Kimi K2.7 Code pour les agents dont les tâches demandent une vraie compréhension de code et des éditions structurantes ;
- —DeepSeek V4 Pro (annonce officielle) pour les tâches intermédiaires, où il faut de la rigueur sans mobiliser un modèle de raisonnement lourd ;
- —DeepSeek V4 Flash (changelog) pour tout ce qui est volume : exploration de repo, lecture massive, transformations mécaniques, tâches répétitives.
L'affectation se fait à la construction de la config, pas au vol. On sait à l'avance quel agent hérite de quel modèle, parce qu'on sait déjà — grâce à l'audit — quel type de travail il va encaisser.
Aucun projet ne tourne sans agent vérificateur. Dès qu'un agent d'exécution termine sa tâche, le vérificateur passe derrière : il contrôle l'intégralité du travail produit, rédige un compte rendu, et rend un verdict binaire — validé ou échoué. Ce compte rendu remonte à l'orchestrateur, pas au développeur.
C'est la pièce que la plupart des setups multi-agents oublient, et c'est celle qui fait toute la différence sur la qualité finale.
Sur chaque projet, on ajoute un agent qui, lui, ne change jamais d'un projet à l'autre : l'agent Deep. Il tourne sous Kimi K3, il peut coder, et contrairement aux autres il n'a aucune zone de responsabilité restreinte — il peut intervenir n'importe où dans le projet.
L'orchestrateur peut l'appeler dans deux cas :
- —il juge d'emblée qu'une tâche est trop complexe pour un agent d'exécution standard ;
- —une tâche a échoué la vérification à plusieurs reprises, et il faut sortir l'artillerie.
L'agent Deep est donc la soupape. Il est coûteux en tokens, mais il n'est sollicité que sur une fraction marginale des tâches — précisément celles qui le justifient.
La boucle de validation
L'ensemble tourne en circuit fermé :
La boucle tourne jusqu'à validation complète par le vérificateur et par l'orchestrateur. Aucun code ne sort du système sans avoir passé ces deux filtres.
Le résultat de cette architecture est le point important : on obtient l'expertise, le jugement et la validation d'un modèle de la classe de K3 sur l'intégralité du travail produit — comme s'il avait codé lui-même — sans qu'il ait écrit une seule ligne. La qualité finale reste très proche de celle d'un K3 en exécution directe, pour une consommation de tokens sans commune mesure.
Ce que ça donne concrètement
Face à Claude Code, on est au minimum au même niveau de qualité, et régulièrement au-dessus. On a besoin de moins de prompts pour arriver au résultat, on y arrive plus vite, et ça coûte moins cher. Beaucoup moins cher, aussi, que d'utiliser K3 directement dans Kimi Code en exécution.
Côté budget, on est passés d'un abonnement Claude à 200 $/mois à un abonnement Kimi à 99 $/mois, plus une enveloppe modeste sur l'API DeepSeek. La facture a fondu ; la qualité, non.
Le point où K3 nous a le plus surpris : la planification
On a comparé K3 et Fable 5 sur des tâches de planification et d'audit, à prompts strictement identiques, mêmes informations en entrée, les deux modèles en max.
Un exemple représentatif, sans entrer dans les détails du projet : on a demandé aux deux de produire un plan d'optimisation pour un système d'IA agentique présentant des problématiques de coût et de latence.
Fable 5 est resté en surface. Il a identifié une optimisation purement technique, correcte, mais il s'est arrêté là.
K3 a posé le même diagnostic technique, trouvé la même optimisation — puis il est allé plus loin : il a proposé en plus une refonte d'interface et d'UX qui, en changeant la manière dont l'utilisateur sollicite le système, réduisait mécaniquement la charge agentique. Autrement dit, une optimisation de coût et de rapidité et une amélioration de l'expérience utilisateur, là où le premier n'avait vu qu'un problème d'ingénierie.
Ce n'est pas un cas isolé. Sur les diagnostics et les reviews, on retrouve la même différence de profondeur régulièrement.
Ce qu'il faut en retenir
Le principe tient en peu de choses : un audit du projet avant de construire la config, un orchestrateur K3 en lecture seule qui planifie et dispatche sans jamais coder, des agents d'exécution assignés selon la difficulté réelle des tâches, un vérificateur systématique, et une soupape d'escalade vers K3 pour les cas qui le justifient.
On obtient le jugement d'un modèle de la classe de K3 sur l'intégralité du travail produit, sans en payer le coût en exécution.
C'est à ce moment-là que l'abonnement devient rentable.
Ulycorp — équipe technique
