Track Kimi account-specific context budgets without reducing model maxima
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
- Domain
- api, authentication, backend
Research direction
Start from src/oauth/kimi.ts (line 155) and src/providers/quota/vendor-probes-key.ts (line 1184) to see identity/expiry and usage/reset parsers. Read Kimi's documented 403 entitlement and the #7630/#7635 review threads to grasp the account-context gap. Implement a verified entitlement source bound to account identity with synthetic fixture tests; done means the 1M model maximum is preserved while account-specific limits gate context admission without inference from quota.
Written by the indexing model from the issue text.
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.
- Dominant language
- TypeScript
- Stars
- 16.9k
- Forks
- 1.3k
- Avg merge
- 9h 39m
- Merged PRs (30d)
- 633
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from lidge-jun/opencodex
-
catalog enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
lidge-jun/opencodex#7704 · 1 comment ·
Maintainers usually reply within 1 day
-
bug streaming
Difficulty 4/5 3-5 days Newbie friendliness 35/100
lidge-jun/opencodex#7720 · 2 comments ·
Maintainers usually reply within 1 day
-
bug gui platform
Difficulty 4/5 3-5 days Newbie friendliness 45/100
lidge-jun/opencodex#7716 · 1 comment ·
Maintainers usually reply within 1 day
-
catalog enhancement
Difficulty 5/5 Over a week Newbie friendliness 30/100
lidge-jun/opencodex#7705 · 1 comment ·
Maintainers usually reply within 1 day
-
bug catalog
Difficulty 4/5 3-5 days Newbie friendliness 55/100
lidge-jun/opencodex#7703 · 2 comments ·
Maintainers usually reply within 1 day
All issues in lidge-jun/opencodex
Similar issues
-
a10y a10y-audit ai-driven-qa claude
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
linagora/twake-directory-manager#219 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
Maintainers usually reply within 1 day
-
0️⃣ phase/new
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Pulse v7: buildPreferencesFromTelos() bypasses telosSectionOrFile(), renders empty on unified-TELOS installsPossibly taken @zephyr91 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
danielmiessler/LifeOS#2393 ·
Maintainers usually reply within 4 days