New model metadata gaps: grok-4.7 falls back to 128K and unconstrained effort in 2.61.0

[HeiTuz]

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.7 is 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.7 reports unconstrained and translates max to max, rather than xhigh.

Logs or error output

Field	Before	After explicit provider maps + ocx sync
catalog context_window / max_context_window	128000 / 128000	500000 / 500000
default_reasoning_level	medium	high
configured ladder	unspecified	low,medium,high,xhigh
inspect-model translation of max/ultra	max	xhigh

opencodex_capability_provenance initially identified xai/grok-4.7 without a context assertion. The parser supplied 128000. ocx sync-cache alone did not rebuild these rows; ocx sync did.

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

1. Use xAI OAuth discovery with grok-4.7 available and no grok-4.7 entries in modelContextWindows/modelReasoningEfforts/modelDefaultReasoningEfforts.
2. Run ocx sync.
3. Inspect the grok-4.7 row in the generated Codex catalog.
4. Run ocx effort model xai/grok-4.7.
5. Compare against https://docs.x.ai/developers/models/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

• Newly discovered anthropic/claude-opus-5-5 had a correct 1M family-derived window and medium default, but no explicit modelReasoningEfforts entry. Its official five-level ladder can now be seeded explicitly: https://platform.claude.com/docs/en/build-with-claude/effort and https://platform.claude.com/docs/en/models/opus-5-5/overview.
• Fable 5.1 and Sonnet 5 catalog defaults were medium, whereas Anthropic documents high. Local per-model defaults corrected this.
• Command Code incomplete ladders are already tracked in command-code: shipped effort ladders are narrower than the live API accepts (and config cannot widen a pinned row) #5096; not asking to duplicate that issue.
• Native OpenAI API limits and Codex runtime caps were deliberately distinguished, not treated as equivalent.

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

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[HeiTuz]

Restart follow-up on 2.61.0: after saving per-model modelContextWindows and modelReasoningEfforts through ocx config set, ocx service restart removed 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.

[lidge-jun]

Ill add in days you can manually change it!

[lidge-jun]

Status from the 260923 bundle round (lane B, #5676): the grok-4.7 context window and effort metadata this issue reports landed on dev with #5599 and is pinned by provider-registry-parity.test.ts. Two parts are not verified yet: grok-4.7-build-fast metadata, and per-model map entries that are lost on restart. Leaving this open for those.

[devin-ai-integration]

Triage: 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]