bug: Chat Completions usage drops cache-write token counts
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 85/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- node.js, typescript
- Ambito
- backend
Direzione di ricerca
I convertitori extractUsage (packages/kosong/src/providers/openai-common.ts) e parseOpenAIUsage (packages/agent-core-v2/src/human/llm/requester/bases/openai/format.ts) scartano i token cache-write. Leggi entrambe le funzioni, aggiungi cache_write_tokens a inputCacheCreation e sottrailo da inputOther. Fatto quando l'output normalizzato corrisponde al inputCacheCreation: 256 e inputOther: 117 attesi.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
What version of Kimi Code is running?
Source checkout at 7ccac2b45b8a3481c76f771bb99c043b562de2c5, including @moonshot-ai/kosong 0.5.6. This is an offline source-function reproduction, not a running CLI session.
Which open platform/subscription were you using?
Moonshot Open Platform Chat Completions response schema. No subscription login or hosted API request was needed for this reproduction.
Which model were you using?
The documented kimi-k3.1-pro usage example.
What platform is your computer?
macOS arm64, Node.js v26.5.0.
What issue are you seeing?
Both Chat Completions usage converters ignore prompt_tokens_details.cache_write_tokens. They return inputCacheCreation: 0 and include those tokens in inputOther instead. The aggregate input count remains correct, but the normalized cache-write breakdown is lost.
The affected conversions are:
What steps can reproduce the bug?
Pass this usage object from the official Chat API example to either converter:
{
"prompt_tokens": 373,
"completion_tokens": 112,
"prompt_tokens_details": {
"cache_write_tokens": 256
}
}
Both currently return the following normalized counters:
{
"inputOther": 373,
"output": 112,
"inputCacheRead": 0,
"inputCacheCreation": 0
}
The v2 converter additionally preserves the original object in raw.
What is the expected behavior?
{
"inputOther": 117,
"output": 112,
"inputCacheRead": 0,
"inputCacheCreation": 256
}
The API documents ordinary input, cache reads and cache writes as mutually exclusive parts of prompt_tokens. Kosong's TokenUsage contract likewise defines inputOther as input that is neither cache-read nor cache-created.
A response with 1,000 input tokens, 600 cached tokens and 256 cache-write tokens should therefore produce 144 ordinary input tokens, 600 cache-read tokens and 256 cache-created tokens. Both converters currently produce 400, 600 and 0.
Additional information
I executed the exact two source functions after stripping TypeScript types. The write-only and read/write cases fail in both implementations; ordinary usage and the legacy top-level cached_tokens cases pass. This was not a package test run, CLI end-to-end test or billing experiment.
This is separate from #2160, which handles partial usage objects without aggregate input counts, and #930, which exposes existing cache counters in the UI. It does not require adding a cache-TTL setting or changing the API's aggregate totals.
The proposed fix is to preserve the reported cache-write count in both existing converters and subtract it from ordinary input, while keeping the existing top-level cache-read precedence and behavior when the new field is absent.
Contribution
- I am willing to submit a PR for this bug fix myself and will wait for a maintainer's
/approvecomment before proceeding with the contribution.
- Lingua principale
- TypeScript
- Stelle
- 7.9k
- Fork
- 1.3k
- Merge medio
- 1g 7h
- PR unite (30g)
- 96
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di MoonshotAI/kimi-code
-
VS Code extension: clickable file links in chat drop the :line suffix, never jump to the lineAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
MoonshotAI/kimi-code#4398 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
MoonshotAI/kimi-code#4395 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
MoonshotAI/kimi-code#4392 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
MoonshotAI/kimi-code#4381 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
MoonshotAI/kimi-code#4369 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di MoonshotAI/kimi-code
Issue simili
-
Native Web
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 80/100
digitalfabrik/integreat-app#4517 ·
I maintainer di solito rispondono entro 2 giorni
-
TLS guide repeats certs/ in the certificate directoryForse già presa @maheshrijal l’ha presa oggi. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
prometheus/docs#3156 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
medusajs/dtc-starter#90 ·
I maintainer di solito rispondono entro 1 giorno
-
usability
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
inmanta/web-console#7632 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
zaidmukaddam/scira#261 ·