command-code: catalog lists models the account gets MODEL_NOT_IN_PLAN (403) for
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 43/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- github, typescript
Research direction
Start by tracing Command Code catalog generation and the handling of POST /v1/responses errors; the issue does not name source files or tests. Check how MODEL_NOT_IN_PLAN responses affect model listing and retries, then verify the catalog omits an unavailable model or drops it after the first 403. Also assess whether the refusal can be returned as non-retryable; the Codex retry behavior and error response are the completion criteria.
Written by the indexing model from the issue text.
Description
OpenCodex can list a Command Code model the account's plan does not include. Codex and GOAT then select it, and every request fails.
Seen on 2026-10-24 (goat-si/goat#1205): a host's Codex model cache and opencodex-catalog.json (written by an older ocx, 2.83–2.86) still offered command-code/google-gemini-4-argon as a selectable model. Requests to it through POST /v1/responses returned:
Provider error 403: {"success":false,"error":{"code":"FORBIDDEN","status":403,"message":"MODEL_NOT_IN_PLAN: Gemini 4 Argon available in Pro and above plans or extra on demand usage"}}
Codex retried it 5/5 times per turn. A newer ocx (2.90.0) no longer lists the model, so this may be partly fixed already. The asks:
- Do not list a Command Code model in the catalog when the account gets
MODEL_NOT_IN_PLANfor it, or drop it after the first such 403. - Consider returning a 403
MODEL_NOT_IN_PLANin a form Codex treats as non-retryable, so a turn does not spend five retries on a refusal that cannot change.
GOAT's side (classify the refusal as a permission error and let fallback chains move past it) is goat-si/goat#1205.
- 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
-
account-pool provider provider-compatibility
Difficulty 4/5 3-5 days Newbie friendliness 45/100
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
All issues in lidge-jun/opencodex
Similar issues
-
freshness freshness:observed-only
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
thoroc/context-radar#282 ·
-
bug P2 rust
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
area: web
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
gabe-santana/arkdraw#25 ·
-
bug require-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
expressjs/expressjs.com#2549 · 1 reaction ·
Maintainers usually reply within 1 day
-
bug good first issue hacktoberfest
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
codercops/discord-bot#101 · 1 comment ·
Maintainers usually reply within 1 day