Skip to content

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

Description

@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

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.

Activity

  1. github-actions commented on Sep 22, 2026

    @github-actions
    Contributor

    Issue reopened

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

  2. added
    bugSomething isn't working
    account-poolOAuth, credentials, Codex pool, quota, failover, plans
    catalogModel catalog, slugs, visibility, routed entries
    on Sep 22, 2026
  3. HeiTuz commented on Sep 22, 2026

    @HeiTuz
    ContributorAuthor

    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.

  4. lidge-jun commented on Sep 22, 2026

    @lidge-jun
    Owner

    Ill add in days you can manually change it!

  5. lidge-jun commented on Sep 23, 2026

    @lidge-jun
    Owner

    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.

  6. added
    priority: P2Medium: provider/client-specific bug with a workaround, bounded enhancement tied to a tracked issue,
    on Sep 24, 2026
  7. devin-ai-integration commented on Sep 24, 2026

    @devin-ai-integration
    Contributor

    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:

  8. lidge-jun commented on Sep 25, 2026

    @lidge-jun
    Owner

    Fixed in v2.65.0, so closing.

    After updating, run ocx sync to regenerate the catalog rows. You can then remove the manual modelContextWindows / modelReasoningEfforts / modelDefaultReasoningEfforts entries 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    account-poolOAuth, credentials, Codex pool, quota, failover, plansbugSomething isn't workingcatalogModel catalog, slugs, visibility, routed entriespriority: P2Medium: provider/client-specific bug with a workaround, bounded enhancement tied to a tracked issue,

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions