Kimi K3.1 Pro : réinitialisation du quota de 25% et API

La réinitialisation annoncée du quota de Kimi K3.1 Pro restitue jusqu’à 25 points de pourcentage de votre quota mensuel d’abonnement ; elle ne promet pas de lever toutes les limites de requêtes. Vérifiez d’abord l’indicateur de consommation mensuelle, puis la fenêtre d’utilisation distincte de Kimi Code si vos requêtes de programmation échouent encore. Si le travail ne peut pas attendre, une API facturée à l’usage permet de continuer avec une facturation indépendante, sa propre clé, son endpoint, son solde et ses limites.

Dans son annonce du 25 octobre, Moonshot a reconnu sa responsabilité dans les problèmes de limites de requêtes et de consommation inutile de quota sur l’abonnement K3.1 Pro. L’entreprise a annoncé une compensation pour les abonnés de tous les forfaits, ainsi que des changements visant à réduire les appels inutiles aux sous-agents et la longueur des réponses.

Les règles ci-dessous reprennent cette annonce et la documentation officielle vérifiée au 2026-10-26.

Quelle quantité de quota la réinitialisation de 25% restitue-t-elle ?

L’annonce revient à soustraire 25 points de pourcentage à la consommation mensuelle, sans descendre sous zéro. Pour un même quota mensuel, en supposant qu’il n’y ait ni consommation supplémentaire ni renouvellement normal du cycle de facturation entre les deux relevés :

used_after = max(0, used_before - 25)

La formule équivalente pour le quota restant est :

remaining_after = min(100, remaining_before + 25)

Chaque valeur représente ici un pourcentage du quota mensuel.

Quota mensuel consommé avant	Consommation attendue après ajustement	Quota restant attendu
18%	0%	100%
25%	0%	100%
60%	35%	65%
100%	75%	25%

Il s’agit d’exemples calculés, pas de résultats observés sur des comptes. Un abonné qui avait consommé moins de 25% récupère uniquement cette quantité consommée ; la formule ne crée pas un quota disponible supérieur à 100%.

La distinction entre pourcentage et points de pourcentage change le résultat. Si l’on réduit de 25% la quantité déjà consommée, un compteur à 60% descend à 45%. L’ajustement annoncé le fait descendre à 35%.

Moonshot a présenté la quantité restituée comme l’équivalent d’une semaine d’utilisation. Cela décrit le volume de la compensation ; ce n’est ni la garantie d’une semaine de programmation, ni un nouveau calendrier de réinitialisation hebdomadaire, ni des jours d’abonnement supplémentaires. Pour votre cycle de facturation habituel, consultez la prochaine date de renouvellement affichée sur la page de votre abonnement.

Le délai annoncé pour mettre à jour la barre de consommation était « end of day PST », soit la fin de la journée PST correspondant à l’annonce du 25 octobre. Vérifiez l’affichage de votre compte après cette échéance : l’annonce ne suffit pas à démontrer que l’ajustement a déjà été appliqué à votre compte.

L’abonnement Kimi, Kimi Code et les clés API partagent-ils le même quota ?

L’abonnement Kimi et Kimi Code partagent le quota mensuel de l’abonnement, tandis que la plateforme publique Kimi API Platform est facturée séparément, à l’usage. Une clé API peut appartenir à l’un ou l’autre de ces systèmes. La présence d’une clé ne permet donc pas, à elle seule, d’identifier le quota consommé.

Les règles d’utilisation de l’abonnement précisent que les fonctionnalités incluses puisent dans une réserve commune de crédits, dont la consommation est mesurée en tokens. Kimi Code ajoute des fenêtres d’utilisation plus courtes à ce quota mensuel.

Le guide actuel des abonnements Kimi Code distingue les nouveaux forfaits des anciens :

Forfaits donnant accès à Kimi Code	Limite sur une fenêtre glissante de cinq heures	Limite hebdomadaire	Quota mensuel partagé
Nouveaux Plus, Pro, Max et Ultra	Applicable	Non applicable	Applicable
Anciens Andante, Moderato, Allegretto et Allegro	Applicable	Applicable	Applicable

Le quota hebdomadaire des anciens forfaits se renouvelle tous les sept jours à partir de la date de souscription. Dans les deux groupes, l’épuisement du total mensuel peut toujours bloquer l’utilisation. Go n’inclut pas Kimi Code ; l’accès à K3.1 Pro exige au minimum le nouveau forfait Plus ou l’ancien forfait Moderato.

Dire sans précision que Kimi n’impose aucune limite hebdomadaire est donc incomplet. Cela décrit les nouveaux forfaits qui incluent Kimi Code, mais pas tous les abonnements existants. La restitution du quota mensuel ne démontre pas non plus qu’une fenêtre de cinq heures, ou une fenêtre hebdomadaire d’un ancien forfait, a été réinitialisée après épuisement.

Les requêtes Kimi Code envoyées depuis sa CLI, Desktop, VS Code et les clients tiers compatibles utilisent les mêmes droits associés au compte. Créer une autre clé API Code ou passer de Claude Code à OpenCode ne crée pas un nouveau quota d’abonnement. Si Extra Usage est activé, il peut permettre de continuer moyennant paiement dans ce même système de facturation.

À l’inverse, la documentation tarifaire de l’API Moonshot décrit explicitement la plateforme publique comme un service facturé à l’usage, distinct de l’abonnement et de Kimi Code. L’annonce de réinitialisation ne confirme aucun remboursement, crédit de solde ou réinitialisation des limites de requêtes pour ce compte API séparé.

Pour une explication plus détaillée des fenêtres, consultez Limites de Kimi Code : cinq heures, quota hebdomadaire des anciens forfaits, quota mensuel et erreurs 429. Les codes de statut associés aux erreurs de quota dans cet article diffèrent de la référence officielle actuelle ; utilisez les correspondances ci-dessous pour diagnostiquer une requête.

Qu’est-ce qui continue de consommer du quota après le changement ?

Le travail utile du modèle consomme toujours des tokens, y compris celui effectué par des sous-agents. Moonshot annonce une réduction des appels inutiles et de la longueur des réponses ; la délégation et les réponses longues ne deviennent pas gratuites.

La documentation des sous-agents Kimi explique que chaque sous-agent travaille dans un contexte indépendant et consomme séparément des tokens du modèle. Déléguer peut donc ajouter des traitements en entrée et en sortie, notamment lorsque plusieurs agents examinent des contenus qui se recoupent. Pour une petite tâche, l’agent principal peut accomplir le même travail avec moins d’appels.

Commencez par une tâche au périmètre limité pour vérifier la consommation. Par exemple, collez ce prompt dans votre client de programmation avec un dépôt ouvert :

Read this repository's README and test configuration.
Identify the command for running its existing tests.
Work in the main agent without spawning subagents.
Do not modify files or run tests.
Answer in at most 100 words, citing the files that establish the command.
If no test command is documented, say so.

Le résultat est vérifiable : la commande permettant d’exécuter les tests du dépôt et l’emplacement des fichiers qui la documentent. Cette tâche permet aussi de repérer une délégation inutile plus facilement qu’une demande générale de revue de tout le projet.

Le prompt donne une consigne, mais n’impose pas un plafond de dépenses strict. Consultez la vue d’activité du client pour vérifier s’il a délégué du travail et évaluez le résultat à partir de la consommation enregistrée. Une réponse visible plus courte ne prouve pas, à elle seule, que l’utilisation totale a diminué.

Gardez le même modèle et les mêmes réglages de raisonnement lorsque vous comparez des exécutions. Le guide de configuration des modèles indique qu’un changement de modèle ou d’effort de raisonnement peut invalider le cache de contexte et augmenter la consommation. Il précise aussi que k3.1-pro-highspeed consomme environ deux fois plus de quota que k3.1-pro standard. Utilisez donc le modèle standard pour évaluer l’efficacité d’utilisation du quota, sauf si la vitesse est votre critère décisif.

Laissez le raisonnement activé : K3.1 Pro rejette les requêtes qui le désactivent. Réduire la longueur de la réponse finale est un réglage différent de la désactivation du raisonnement.

Comment vérifier la réinitialisation et la baisse de consommation ?

Vérifiez la restitution du quota séparément du coût d’une nouvelle tâche. Observer les deux en même temps peut masquer leurs effets : l’ajustement fait baisser l’indicateur de consommation pendant qu’un autre agent en cours d’exécution le fait monter.

Relevez les bons indicateurs. Dans l’interface web de Kimi, ouvrez votre avatar → Settings → Subscription. Notez le forfait, si le pourcentage affiché correspond à la consommation ou au quota restant, la prochaine échéance de renouvellement, ainsi que la date et l’heure avec le fuseau horaire. Dans Kimi Code, exécutez aussi /usage et consultez l’état des fenêtres plus courtes dans la Console.
Comparez l’ajustement sans autre activité. Mettez en pause les autres sessions qui consomment le quota de l’abonnement pendant cette vérification. Si vous avez conservé un relevé antérieur à l’ajustement, comparez-le à la formule ci-dessus une fois la mise à jour affichée. Tenez compte des tâches intermédiaires et du renouvellement mensuel habituel ; sans relevé antérieur, la barre actuelle ne permet pas de reconstituer exactement le crédit restitué.
Mesurez une petite tâche une fois l’ajustement appliqué. Relevez la consommation juste avant d’envoyer le prompt limité au dépôt, puis consultez l’enregistrement de consommation de la tâche après sa fin. La FAQ sur l’utilisation de Kimi décrit ces relevés et précise que leur affichage peut subir un léger retard.
Comparez des travaux équivalents. Conservez le même dépôt, modèle, réglage de raisonnement, ensemble d’outils disponibles et objectif. Notez les informations de cache lorsqu’elles sont disponibles au lieu de supposer que deux exécutions ont des conditions de cache identiques. Comparez le quota consommé et vérifiez que la réponse a réellement accompli la tâche.

Sans exécution antérieure comparable, cette mesure fournit une référence pour les travaux suivants ; elle ne prouve pas combien un changement côté serveur a permis d’économiser. Si le pourcentage affiché manque de précision pour distinguer une petite requête, consultez le relevé détaillé avant de consommer davantage de quota en répétant les essais.

Si les requêtes échouent encore, examinez le message complet. Au 2026-10-26, la référence officielle des erreurs Kimi Code classe les cas suivants sous le statut HTTP 429 :

Message Kimi Code	Vérification à effectuer
`You've reached your 5-hour usage limit`	Consultez dans la Console l’heure de réinitialisation de la fenêtre de cinq heures.
`You've reached your weekly (7-day) usage limit`	Vérifiez la fenêtre hebdomadaire de l’ancien forfait.
`You've reached your monthly usage limit for this billing cycle`	Vérifiez l’indicateur mensuel partagé et l’ajustement.

Répéter les requêtes ne reconstitue pas un quota épuisé. La surcharge du serveur est une situation distincte : un crédit mensuel rétabli peut donc coexister avec une requête qui échoue.

Si l’ajustement promis reste absent après l’échéance annoncée et après la mise à jour de l’affichage, contactez le support des abonnements Kimi. Fournissez le forfait, les dates et heures, ainsi que des relevés avant et après l’ajustement dont vous avez masqué les données sensibles.

Quand passer à une API facturée séparément ?

Choisissez une solution facturée à l’usage lorsque la tâche justifie un paiement indépendant et qu’attendre le renouvellement d’une fenêtre de l’abonnement bloquerait le travail. Si conserver la session Kimi actuelle est prioritaire, vérifiez d’abord si votre compte propose Extra Usage. Ce portefeuille payant est commun à Kimi et Kimi Code ; activez son plafond mensuel de dépenses avant de compter dessus pour continuer.

Choisissez le mode de facturation et estimez le budget

L’endpoint, l’identifiant du modèle et la provenance de la clé doivent correspondre au même service. Voici les URL de base internationales compatibles avec OpenAI ; les configurations Anthropic propres à chaque outil utilisent des chemins de base différents.

Service	URL de base	Identifiant de K3.1 Pro standard	Facturation
Kimi Code	`https://api.kimi.ai/coding/v1`	`k3.1-pro`	Quota de l’abonnement ; Extra Usage peut prendre le relais pour les comptes éligibles
Kimi API Platform	`https://api.moonshot.ai/v1`	`kimi-k3.1-pro`	Compte API séparé, facturé à l’usage
BetterToken	`https://www.bettertoken.ai/v1`	`kimi-k3.1-pro`	Solde API BetterToken distinct

Le catalogue de modèles de BetterToken répertoriait kimi-k3.1-pro le 2026-10-26 avec un accès par Chat Completions et Anthropic Messages. Son guide du modèle précise que Responses n’est pas activé pour ce modèle. Il s’agit d’un accès API indépendant, pas d’un quota d’abonnement Kimi.

Pour donner un ordre de grandeur, les tarifs mondiaux actuels de l’API Moonshot indiquent $2 par million de tokens d’entrée ordinaires et $10 par million de tokens de sortie pour kimi-k3.1-pro standard, avant les taxes applicables. Une requête hypothétique utilisant 100,000 tokens d’entrée au tarif de $2 et 10,000 tokens de sortie facturés au total coûte :

(100,000 / 1,000,000 × $2) + (10,000 / 1,000,000 × $10) = $0.30

Cette estimation suppose l’absence d’appels à des outils payants, de lectures depuis le cache et d’écritures en cache d’une heure. Les écritures standard en cache de cinq minutes coûtent également $2 par million de tokens ; un token classé comme écriture en cache n’est pas facturé une seconde fois comme entrée ordinaire. Utilisez le nombre de tokens facturés, pas la longueur de la réponse visible.

BetterToken applique ses propres tarifs actuels. Un pourcentage de consommation de l’abonnement ne permet pas de déterminer quelle solution revient moins cher, et une tâche d’agent peut entraîner de nombreuses requêtes au-delà de sa réponse finale visible.

Vérifiez une requête avant de changer la connexion de l’agent

Pour utiliser BetterToken, sélectionnez votre propre clé API dans la console, confirmez l’accès au modèle et le solde disponible, puis envoyez une petite requête. L’exemple suivant respecte le format documenté ; il n’a pas été exécuté sur un compte d’inférence payant pour cet article.

Utilisez Bash, avec curl et jq installés. Lorsque read attend une saisie, collez votre clé et appuyez sur Entrée ; la saisie reste masquée.

set -o pipefail
read -rs BETTERTOKEN_API_KEY && export BETTERTOKEN_API_KEY

curl --silent --show-error --fail-with-body \
  https://www.bettertoken.ai/v1/chat/completions \
  --header "Authorization: Bearer ${BETTERTOKEN_API_KEY:?API key is required}" \
  --header "Content-Type: application/json" \
  --data '{
    "model": "kimi-k3.1-pro",
    "stream": false,
    "messages": [
      {"role": "user", "content": "Reply with exactly: API_OK"}
    ]
  }' |
jq '{
  model,
  answer: .choices[0].message.content,
  finish_reason: .choices[0].finish_reason,
  usage,
  error
}'

Le corps de la réponse contient le résultat ; cette requête sans streaming ne nécessite pas d’interroger périodiquement l’état d’un traitement. Vérifiez que la réponse contient le texte demandé, API_OK, qu’elle est terminée et qu’elle inclut les informations de consommation. Avant de déplacer une tâche plus importante, retrouvez la requête dans le tableau de bord BetterToken et vérifiez le modèle, le statut, les tokens consommés et le montant facturé.

Pour continuer dans Cline, ouvrez Use your own API key, choisissez OpenAI Compatible, puis saisissez l’URL de base BetterToken du tableau, votre clé BetterToken et kimi-k3.1-pro. Enregistrez, rechargez l’extension et commencez par la même petite tâche sur le dépôt. Pour OpenCode, suivez sa configuration de fournisseur Chat Completions personnalisé.

La configuration BetterToken de Claude Code utilise la base compatible Anthropic https://bettertoken.ai, sans /v1. Suivez les instructions d’authentification propres à cet outil plutôt que de copier la base Chat Completions dans sa configuration.

Si le test initial renvoie 401, vérifiez à nouveau la clé BetterToken. Pour un 404 ou une erreur de recherche du modèle, vérifiez l’endpoint et l’identifiant exact du modèle. En cas d’erreur de limite de requêtes ou de solde, consultez la réponse et le tableau de bord de ce compte API avant de réessayer ; la réinitialisation de l’abonnement ne permet pas de déduire l’état d’un service facturé séparément.