Grok 4.7 hits 60 percent on Vals Index but task cost nearly triples

The latest SDK update delivered a solid performance bump for Grok 4.7, lifting it from 54 percent to just over 60 percent on the Vals Index. The gain comes with a steep price tag: cost per task has nearly tripled. Model researcher Lisan al Gaib surfaced the discrepancy on X and flagged it as "still suspicious," pointing to a token-usage anomaly that no routine optimization easily explains.

Vals Index benchmarks a model's ability to handle coding and engineering tasks against live runtime environments, not just static knowledge questions. A six-percentage-point jump looks impressive on paper, but when you translate it into actual spend — three times more dollars per completed task — the cost-benefit ratio flips. In production terms, an organization running the new version at the same workload would triple its API bill without getting proportional throughput.

The cache anomaly: 90 percent versus 47 percent

Lisan al Gaib's analysis zeroes in on the input-token caching mechanism. In version 4.6 the working assumption is that roughly 90 percent of tokens come from cache, meaning requests reuse the same context and make efficient use of memory. In version 4.7, to account for the cost spike, you have to assume only 47 percent of tokens are pulled from cache. A drop that sharp in cache-hit rate isn't explained by standard SDK changes; it hints at a fundamental shift in how the model builds context or a bug in the cache itself.

Length penalty in the RL loop

According to a source close to development, the reinforcement-learning (RL) process may have over-penalized long responses, causing the model to bail on hard tasks too early even when it can solve them. It's a known dynamic: when the reward function pushes for brevity, the model learns to "escape" extended reasoning chains that actually lead to the right answer. The result is paradoxical — the benchmark score rises because easy tasks get solved faster, but hard tasks get abandoned, and overall cost climbs because the model spins through more trial-and-error rounds before giving up.

Musk's answer: xhigh and Grok Build

Elon Musk replied directly to the thread and laid out his fix: enable "xhigh" mode in version 4.7, alongside a tool called Grok Build. The phrasing — "Godspeed, you glorious bastard… Per aspera ad Astra" — leaves little doubt about the tone. This isn't a dry engineering patch; it's an aggressive push to the edge of capability, likely at the expense of compute efficiency. The xhigh mode presumably expands the token budget and allows deeper search across the solution space, which would explain both the score improvement and the cost surge.

What this means for developers building on Grok

The bottom line: version 4.7 with the updated SDK delivers higher benchmark numbers, but only for teams willing to foot the bill. Anyone running in production with cost sensitivity should audit their own cache-hit rate before upgrading and decide whether xhigh mode fits their use case or just inflates the invoice. For now, the gap between 54 and 60 percent on Vals Index looks less like a breakthrough and more like a deliberate trade-off Musk is happy to make.