Repository navigation
New model metadata gaps: grok-4.7 falls back to 128K and unconstrained effort in 2.61.0 #5576
Description
Activity
github-actions commented
on Sep 22, 2026 on Sep 22, 2026 – with GitHub ActionsContributorMore actionsIssue reopened
The report now contains the information required by the automated check. Thanks for updating it.
- addedbugSomething isn't workingSomething isn't workingaccount-poolOAuth, credentials, Codex pool, quota, failover, plansOAuth, credentials, Codex pool, quota, failover, planscatalogModel catalog, slugs, visibility, routed entriesModel catalog, slugs, visibility, routed entries
on Sep 22, 2026 Restart follow-up on 2.61.0: after saving per-model modelContextWindows and modelReasoningEfforts through
ocx config set,ocx service restartremoved the new grok-4.7 / claude-opus-5-5 map entries in this installation (modelDefaultReasoningEfforts remained). The next sync returned Grok to 128000. Root cause within startup/rebase is not yet isolated.A durable local workaround was verified:
ocx models add xai grok-4.7 --context-window 500000 --modalities text,image --reasoning-efforts low,medium,high,xhigh --default-reasoning-effort high. After service restart plus sync the catalog retained 500000/high. An analogous custom registration preserved Opus 5.5's explicit 1M/five-level/medium metadata. This is preferable to treating a pre-restart read-back of provider maps as persistence proof.Ill add in days you can manually change it!
Status from the 260923 bundle round (lane B, #5676): the grok-4.7 context window and effort metadata this issue reports landed on
devwith #5599 and is pinned byprovider-registry-parity.test.ts. Two parts are not verified yet:grok-4.7-build-fastmetadata, and per-model map entries that are lost on restart. Leaving this open for those.- added 3 commits that reference this issue
on Sep 24, 2026 - addedpriority: P2Medium: provider/client-specific bug with a workaround, bounded enhancement tied to a tracked issue,Medium: provider/client-specific bug with a workaround, bounded enhancement tied to a tracked issue,
on Sep 24, 2026 devin-ai-integration commented
on Sep 24, 2026 ContributorMore actionsTriage:
priority: P2— grok-4.7 metadata gaps (context/effort fallback).Criteria (P2): Medium: provider/client-specific bug with a workaround, bounded enhancement tied to a tracked issue, perf, or CI reliability.
Matched pull requests:
- [WRONG BRANCH] fix(effort): run wire mapper on unpinned/unconfigured effort values #5539 (related / partial) — [WRONG BRANCH] fix(effort): run wire mapper on unpinned/unconfigured effort values [
priority: P2]
- [WRONG BRANCH] fix(effort): run wire mapper on unpinned/unconfigured effort values #5539 (related / partial) — [WRONG BRANCH] fix(effort): run wire mapper on unpinned/unconfigured effort values [
Fixed in v2.65.0, so closing.
grok-4.7: feat(providers): grok-4.7 parity with grok-4.6 across xAI, Devin, OpenCode Go, Command Code and Cursor #5599 publishes the documented contract (500K context,low..xhigh, defaulthigh) without per-model overrides.tests/providers/provider-registry-parity.test.tspins it.grok-4.7-build-fast: fix(providers): bundle L3 — MiMo, DeepSeek, Google, Command Code and xAI adapter fixes #5739 gives the discovered ID the same 500K window and effort ladder, following xAI's description of Grok 4.7 Fast as the same model served on faster infrastructure.
After updating, run
ocx syncto regenerate the catalog rows. You can then remove the manualmodelContextWindows/modelReasoningEfforts/modelDefaultReasoningEffortsentries for these models.#5739 left one related finding out of scope: per-model maps being lost on restart. If you still see that on v2.65.0, please open a separate issue so it can be tracked on its own.
Client or integration
Codex App
Area
Catalog / models
Summary
On OpenCodex 2.61.0 (macOS, Codex runtime 0.155.1), newly discovered xAI
grok-4.7is published with a 128,000-token context and a generic reasoning ladder/default when no per-model override exists. The official contract is 500,000 tokens, low/medium/high/xhigh, default high.This is separate from synthetic max/ultra picker compatibility discussed in #2420: before adding the missing ladder,
ocx effort model xai/grok-4.7reports unconstrained and translates max to max, rather than xhigh.Logs or error output
opencodex_capability_provenanceinitially identified xai/grok-4.7 without a context assertion. The parser supplied 128000.ocx sync-cachealone did not rebuild these rows;ocx syncdid.A second discovered ID,
xai/grok-4.7-build-fast, still has 128000 and the generic ladder. I have NOT assumed the public API model's limits apply to that OAuth/gateway-specific ID; it needs authoritative gateway metadata or a verified contract.Reproduction
ocx sync.ocx effort model xai/grok-4.7.Redacted configuration
Merge these entries into the existing xai provider maps (do not replace unrelated model entries):
{ "modelContextWindows": {"grok-4.7": 500000}, "modelReasoningEfforts": {"grok-4.7": ["low", "medium", "high", "xhigh"]}, "modelDefaultReasoningEfforts": {"grok-4.7": "high"} }The regenerated catalog and effort inspection were read back. This was metadata/translation verification, not a 500K input load test or captured generation request.
Related audit findings
Suggested fix and validation
Add exact new-model metadata to registry seeds and ensure discovery enrichment uses it. Keep unknown gateway variants explicitly unresolved instead of presenting parser fallback values as verified limits. Add a regression for discovered grok-4.7 context/default and max-to-xhigh wire mapping. Preserve synthetic client compatibility only with clear provenance.
No credentials, account identifiers, user prompts, or private configuration are included.
Version
2.61.0 (Codex runtime 0.155.1)
Operating system
macOS 26.6.2
Provider and model
xai / grok-4.7; related anthropic / claude-opus-5-5 metadata
Checks