Composite score ties GPT-5.6, but Fable 5 wins the most individual tests

The headline claim is "tying GPT-5.6 Sol on the AA Intelligence Index (Artificial Analysis Intelligence Index)." GPT-5.6 Sol is OpenAI's current flagship model. This index is a composite score synthesized from nine tests:

The company also released a table with the ten individual scores. When you count the first-place finishes, the story changes:

Count the first-place finishes: Fable 5 Max took 5, Grok 4.6 took 3, and GPT-5.6 Sol Max took 2. So the "ties GPT-5.6" claim only holds for the nine-test composite score. In the individual breakdown, Fable 5 Max is the biggest winner.

Grok 4.6's strengths are concentrated in two areas: knowledge work and legal. It took first place in both knowledge work tests (GDPVal-AA 1753, AA-Briefcase 1577). The legal gap is the most dramatic: it scored 15.8% versus GPT-5.6 Sol Max's 2.5% — a six-fold difference.

The weakness is also clear: Terminal-Bench at 26%, while GPT-5.6 is at 34.6% and Fable 5 at 34.1% — a gap of over eight points. This tests the ability to work in a terminal. The official write-up doesn't mention this benchmark; it's only visible in the table.

Compared to its own predecessor, the gains are real: Terminal-Bench up from 15.7% to 26%, APEX-Agents from 47.1% to 57.5%, DeepSWE from 54% to 65.9%, and AA-Briefcase from 1313 to 1577.

One sentence in your prompt outperformed a two-page spec

In long tasks, the company observed a shift: the model started testing itself, checking its own work after each step before moving on.

In real-world testing, this behavior turns out to be a switch you can explicitly flip with a single sentence.

Here's the setup. Two models were each given the same task — "build a spreadsheet app" — and ran it twice. One time they got a two-page specification covering every toolbar button, every shortcut, and every formula. The other time they got just three sentences:

The results were nearly identical. What actually changed the outcome was adding this one sentence:

With that addition, the model would open the app itself, click through a real user path, check if nested formulas were calculating correctly, and then fix the issues it found. This was the single highest-leverage thing he did in those weeks.

This loop only works if the model is good enough at browser operation. Without the ability to "open it and take a look," none of the rest is possible.

Output comparison between the two prompt lengths. All subsequent comparisons used the same prompt in isolated workspaces for each model, not from memory of last month. Image / Eric Zakariasson

What happens if you skip the verification step

A counter-example comes from the Excalidraw project later on. After one run, the summary sounded like everything was done, but the "add view" feature didn't actually work. It took a simple "run it and show me" to expose the broken import.

Prompt wording didn't matter. Length determined who was in charge.

The same batch of experiments also tested prompt style, and the conclusion breaks down into three points.

The long spec isn't dead, though. He gave a detailed spec for a feedback component, including session capture, server-side handling, and cloud agent dispatch. The model followed it end-to-end and the structure was sound. But one specific flaw emerged: unless explicitly asked to modularize, it repeated itself within components.

The harder an output is to self-check, the more you have to watch it

The most transferable takeaway from the entire review is this: wherever manual intervention was needed, the root cause was the same — whether the model could verify its own work.

So there are only two practical countermeasures: either give it a way to "see," or accept that you'll have to check the work yourself.

The same logic applies to outputs that are hard to check. Telling a 3D scene to "improve the textures" led nowhere. Switching to the sentence below worked immediately:

Five projects tested: 4.6's first drafts were noticeably more complete

The six clips below all used the same prompt, running 4.5 and 4.6 side-by-side in isolated workspaces. This is not from memory of last month.

After several days, video was where the models diverged the most. Two models that feel evenly matched on web apps can be worlds apart here.

Denser summaries, faster responses, workflow shifts from async back to sync

Beyond the outputs, the way it feels to use has changed too.

The speed difference had a bigger impact. 4.5 was also fast, but 4.6 is both faster and noticeably smarter, and that combination pushed the workflow back toward sync: instead of pre-loading a huge context and waiting, you ask for a small piece, look at it, and move on. If you want to shift into a long-running task within the same session, you just say so.

The trade-off is real: async lets it do more work while you're away, but you lose context and end up cold-reviewing a big diff. When you actually care about the outcome, sync is the better place to be.

Grunt work it quietly took over

Most of the weeks were ordinary tasks: navigating websites for him (including going into a provider's console to create an API key), doing functional and visual QA on a running app, triaging an inbox down to the emails that genuinely needed a reply, drafting launch tweets for two features, and producing their launch videos with Remotion.

Where he still intervened personally

He still got involved in work where the output is judged by "does it look good" — animation, 3D, final polish. That kind of work needs a reference image plus a screenshot loop, not a text description. He also wrote down acceptance criteria instead of trusting a "done" summary.

His reason for making 4.6 his default isn't that it's the best at any one thing: some models are sharp, exceptional at one specific task. But everyday work isn't one specific task. He wants a model he knows well enough to predict its behavior, reliable enough to hand work off to, and with quirks familiar enough to work around automatically.

Prompt templates and usage guide you can copy directly

These are from the weeks of testing. The English is the original wording, and you can use it verbatim.

Verify the function and design after implementation, and keep on iterating and verifying until it's production ready.

Add this to the end of the task description. It makes the model open the app itself, click through a real user path, check if the calculations are correct, then fix what it finds. This was the highest-leverage change in those weeks.

capture the current frame, list what's wrong with it, then fix only those things

run it and show me

The third one looks simple, but it's exactly what exposed a situation where the summary said "done" and the feature was broken — a bad import.

Build a polished Sheets/Excel-style app in Next.js and an AI chat that can analyze the sheet. Use the Cursor SDK for all AI features. Preload a realistic sample workbook so it looks good immediately.

Phrases that didn't work

Seven usage tips

How to use it: access points, pricing, double first-week credits

There are three main entry points: Cursor, Grok Build, and the official API (console.x.ai). It's also available through OpenRouter, Vercel, Cloudflare, and others.

Pricing is $2 per million input tokens and $6 per million output tokens, same as 4.5. The fast version is double, but the speed increase isn't specified. The first week includes double credits in Grok Build and Cursor.

The headline is "ties GPT-5.6 Sol" on the AA Intelligence Index (a composite score from nine tests by Artificial Analysis). But when you count first-place finishes across the ten individual benchmarks, the story is different.

Grok 4.6 is strong in knowledge work and legal. Its weakness is terminal work — a benchmark not mentioned in the official write-up, only visible in the table. All scores are self-reported by xAI; competitor numbers are the best publicly available figures. No independent third-party re-testing.

An engineer who used Grok 4.6 as his daily driver for weeks ran a controlled comparison. For the same spreadsheet app task, one run got a two-page spec (every button, shortcut, formula detailed), the other got just these three sentences. The results were nearly identical.

With that added, the model opens the app itself, clicks through a real user path, checks nested formulas, and fixes what it finds — assuming its browser operation skills are good enough. This aligns with xAI's observation in long tasks: the model starts checking its own work before moving on. That's the observation on one side, and a switch you can flip on the other. The same batch of tests found that prompt wording and length had little impact. What moved the needle was the verification ask.

The times you need to step in all point to the same thing: whether the model can verify its own work. Websites are easiest. 3D is harder. Video and physics are hardest.

Telling a 3D scene to "improve the textures" got nowhere. Switching to "capture the current frame, list what's wrong with it, then fix only those things" worked immediately. Give it a way to see, and half the problem is solved.