Repository navigation
Track Kimi account-specific context budgets without reducing model maxima #7708
Description
Client or integration
Codex CLI / Claude Code through OpenCodex Kimi Coding presets.
Provider or upstream service
Kimi Code subscription endpoints, separate from Moonshot platform model-catalog work.
OpenCodex version
Source reviewed at 26598df2c4c07d781e344ac6119953fed77ecb27. This tracks a design gap, not a reproduced live-account incident.
Endpoint or capability
Account-specific context budgets for model admission, context publication and compaction.
Current behaviour
The registry preserves the 1,048,576-token maximum for K3.1 models. That maximum should remain available to eligible accounts. However, the reviewed Kimi OAuth parser supplies identity and expiry, and the quota parser supplies usage/reset data; neither establishes a verified account context entitlement.
Expected behaviour
Keep the model maximum separate from an effective limit verified for the selected account. Kimi documents a 403 for accounts limited to 256K when requesting K3.1 Pro's 1M context. Missing or stale entitlement must remain unknown, rather than being inferred from quota percentages, model names or display labels.
Minimal redacted request or reproduction
No provider or paid inference request was sent. The gap is supported by the documented account distinction and the inspected metadata paths. Synthetic capability/account fixtures should drive implementation tests.
Actual response or error
No local account response was captured. The documented entitlement refusal is distinct from quota exhaustion and ordinary context overflow; it should not trigger an undifferentiated compaction/retry/failover send.
Upstream documentation
Kimi Code error reference. An authenticated capability endpoint/schema suitable for this integration has not yet been established.
Suggested mapping or implementation notes
- Establish an authoritative capability source before assigning numeric account limits.
- Bind observations to provider origin, account identity and credential generation; define freshness, refresh and stale-completion handling.
- Apply verified limits consistently at account selection and context admission/publication/compaction, without sharing one account's budget with another.
- Cover unknown/stale/malformed evidence, account changes and entitlement-denial handling with synthetic tests. Preserve the global 1M maximum and existing retry/send budgets.
Additional context and attachments
This is the follow-up agreed in the #7630 review and #7635. #7653/#7695 concern Moonshot catalog changes, not account-specific context eligibility.
Checks
- I searched existing provider and compatibility issues.
- No credentials, account identifiers, or live request/response data are attached.
- Expected behaviour follows the upstream documentation and linked review agreement.
Activity
lidge-jun commentedon Oct 28, 2026
At dev@fdc6dd82d, Kimi token parsing returns identity, grant and expiry (src/oauth/kimi.ts:155-186); quota parsing produces usage/reset windows (src/providers/quota/vendor-probes-key.ts:1184-1218). Neither establishes an account context entitlement. The registry intentionally retains the 1,048,576-token model maximum (src/providers/registry/model-seeds.ts:754-762). Kimi’s current error reference distinguishes a subscription-limited 256K context refusal from quota exhaustion. That documents the distinction, not an authenticated capability-response schema.
There are three possible sources: an authoritative account-capability response, an explicit operator context ceiling, or a narrowly classified refusal observed during a real request. The first supports positive entitlement but needs a verified endpoint/schema. An operator ceiling is useful for voluntarily reducing context, but cannot grant access. A refusal can establish that a particular request was denied; it cannot establish every supported model budget or safely authorize a positive 1M claim.
I recommend the authoritative source for numeric entitlement, with an explicit unknown state until evidence exists. Define one observation as origin + account identity + credential generation + exact model capability + observation/expiry times + provenance. The request should capture its account budget after account selection and revalidate it at physical dispatch. Publication to clients and compaction must consume that same effective budget; a shared catalog row must never inherit whichever account was inspected last. Where several accounts remain possible, publish uncertainty or a clearly defined conservative bound, not one account’s entitlement as universal.
Compatibility should preserve existing model maxima and avoid automatic account migration. Missing, stale or malformed evidence must not become either a guessed 256K entitlement or a 1M grant. Existing compaction recovery already protects HTTP 403 (src/server/responses/compaction-recovery-policy.ts:92-95); do not describe that protection as missing or reinterpret entitlement denial as context overflow.
No safe numeric-budget implementation slice is established yet. What unblocks it is an agreed authoritative source, its redacted schema and freshness/invalidation semantics, plus the client publication rule for an unresolved account. After that, use a provider-owned observation module beside
src/oauth/kimi.ts, keeping quota parsing separate, and a proposedtests/providers/kimi-context-budget.test.ts. Synthetic fixtures should cover two accounts with different limits, origin changes, credential replacement during an awaited read, unknown/stale responses, unchanged global maxima and denial with no extra automatic send. No paid capability probe is needed for that test contract.