Back to Blog

Don't Sleep on Grok 4.6: What My Own Testing Found

Okay, so I have been using Grok 4.6 for serious work this week, which is not a sentence I thought I would type. Six months ago I would probably have laughed at the idea. I had largely written Grok off. For anything autonomous I defaulted to Claude, particularly Fable 5, and that was not a close call. I run EF-Map, an interactive map for EVE Frontier, plus a handful of private repos around it, and I was pretty sure I already knew which model sat in the middle of that loop.

That has changed surprisingly quickly.

xAI released Grok 4.6 with a fairly specific pitch. The interesting part, as far as I can tell from their own write-up, is not a new chatbot personality. It is long-running agents. Grok Build is their terminal agent, and /goal is the mode that keeps going until the job is finished and checked. A Reddit post was doing the rounds at the same time, arguing that this is where Grok had actually moved, on long agent jobs rather than on whoever is currently topping a chart. I treated that as a prompt to go try it, not as evidence.

I have real private codebases. Large test estates. Deployment procedures. Work I actually needed done. So I started giving Grok those jobs and watching what happened.

Why I did not start with a leaderboard

I have read enough model launch posts. The chart is never the thing I am trying to decide. What I am trying to decide is whether I can leave a well-specified job overnight and wake up to a branch I would actually merge after a smoke pass.

That is a different question. A model can look excellent on a coding bench and still wander off a long contract. It can also burn the weekly allowance on something it never quite finishes, or leave me a preview that looks fine until I right-click something.

I wrote about the Fable version of this loop last week, the unattended overnight run that built a subscriber feature while I was asleep. That article is still true. Fable is still the model I trust most when the job is ambiguous or the recovery is hard. This one is about what happened when I stopped treating Grok as the thing I would never hand that kind of work to.

The bounded EF-Map nights

The first jobs were the sort of engineering nights I have been putting on a roadmap since the test suite started arriving on its own. I have written about that shift already, the point where a vibe coder accidentally acquired software engineering. Unified E2E Matrix night asked for one command that says the EVE Frontier map still works. Frontend Chaos night asked the same harness to start breaking things on purpose. Telemetry Integrity night asked whether the numbers the site reports about itself are actually true.

Those are not glamorous jobs. They are exactly the jobs I now want an agent to take, because they are well specified, they have a contract, and the repo can prove a lot of the result without me hovering.

Some of the night contracts name Grok 4.6 in Grok Build. The others I ran as Grok 4.6 sessions on purpose.

Unified E2E landed a real test:e2e runner, folded the existing browser scripts, added the must-ship new cells, and closed on a Pages preview. The final preview ran the matrix twice, smoke 5/5, with the unit suite green.

Frontend Chaos filled the empty fault-injection mode that night had left behind. The interesting bit is that it did not quietly paper over the product. The first closeout claimed a clean 9/9, including offline, and then a correction pass recast the night as partial because the offline cell had repaired cache storage instead of proving the shipped fallback. That is a slightly embarrassing kind of success. The harness landed. The honest result was 8 passed and 1 skipped, and three real product bugs got names: the offline fallback on pretty URLs was unusable, a malformed universe database with an HTTP 200 could poison IndexedDB, and a genuine first-load database failure had no Retry.

The chaos night found those. It left a harness that can fail them. Same-day follow-up branches on other work closed F-4, F-3 and F-1 and they shipped. I am not claiming Grok wrote those product-fix branches. Finding them unattended was still the useful part of that night.

Telemetry Integrity was the most "is this even true" of the three. It shipped a named enumerator for the event map, joined it to the actual producers, modelled the queue, and fixed a short list of confirmed defects: empty POSTs, a fetch('null'), a keepalive hole, a duplicate theme effect, a helper getting overwritten. The census is 191 event-map keys and 184 live producers, with 7 historical orphans left classified rather than deleted. It did not get a Pages preview on purpose. The stats namespace on preview is the production namespace, and an integrity night that writes there would be a joke.

What those nights actually produced

RunWhat actually landedScale I can stand behind
Unified E2E Matrixone test:e2e command wrapping the browser suite10 commits, 28 product files, 1,402 lines added; smoke 5/5; 7,194 unit tests green
Frontend Chaosfault-injection mode of that harness11 commits, 12 product files, 1,757 lines added; chaos 8 passed, 1 skipped before the later product fixes
Telemetry Integrityevent-map census, queue proofs, bounded client fixes14 commits, 15 product files, 1,183 lines added and 97 removed; 191 keys, 184 producers; 7,280 passed, 130 skipped
EO Jump Plannernew capital, Black Ops and jump-freighter routing tab2 commits, 38 product files, 2,919 lines added; 24 of 24 planner smokes; 5,797 unit tests on that tree

Those numbers are from git and the night ledgers, not from a vendor slide.

The harder test

The EF-Map nights are bounded. A good contract, a repo that already knows how to test itself, a night that is allowed to ledger a finding instead of inventing a product change. Useful, but not the whole question.

The harder test was a feature on a sibling repo, EO-Map, which is the EVE Online map I am converting from this EVE Frontier one. The job was a Jump Planner tab. Hull-specific journeys, fuel, fatigue, waypoints, avoidance, a preference for NPC-station midpoints, and mixed jump-plus-stargate routing as a serious first version rather than a nice-to-have. The contract is long on purpose. I have learned that unattended work dies when the document still contains a question.

Grok took that contract and produced a branch. A worker, a search, legality, fuel, fatigue, copy in all seven locales, a 24-check browser smoke, and a real-graph test file that pins the reference fuel figure. Typecheck clean. It deployed an isolated preview and I went to click on it.

That is further than I expected one autonomous run to get.

Two of them at once

While that session was running I started a second Grok 4.6 High session on the same Windows machine, in the EF-Map repo, on Telemetry Integrity. Separate repositories. Separate branches. Separate local port ranges, 5175 against 5185, written into the contracts so neither agent was allowed to kill processes it could not prove it owned.

I wanted to know whether concurrency was even real. Not whether two chat windows can stay open. Whether two substantial jobs would finish without standing on each other's Chrome, or Node, or preview server.

They both finished, Telemetry Integrity closed complete and later shipped, and Jump Planner closed on a preview. Neither session reported anything I would call machine contention. If I can run two of these at once, the weekly allowance becomes a different kind of constraint.

I should say what that session looked like from the outside, because git will not tell you. The Jump Planner Grok UI showed almost 52 million input tokens and 286 model calls. That is a reading from the session screen, not an API invoice, and I am not turning it into a dollar figure I did not measure. It is just the shape of the thing, not a prompt so much as an agent spending a working day inside a repo.

Where I still had to catch it

I smoke-tested the first Jump Planner preview the way I smoke-test anything I am going to put in front of people. I right-clicked a system and hit Set Destination.

It went to Point-to-Point.

The planner tab was open. The new form was on screen. The right-click actions still targeted the older routing surface. Once you see it, it is obvious. The committed code only special-cased a hidden tab the product does not even show, then fell through to the Point-to-Point events. Jump Planner was not a routing target at all.

There was a smaller one too. The first plan could run before the NPC-station data had loaded, so a prefer-NPC-midpoints search could start against an empty set.

Those are real misses. A human found the first one in the first minute of using the preview. A later pass on the same branch has already closed both of them, so they are not current bugs. They were the cost of the first preview.

The conclusion I actually drew is not that Grok replaces human review. It is closer to this. Grok got a genuinely difficult feature much further in one unattended run than I expected, and the remaining correction cost was small compared with the amount of work it completed without me.

That is the same lesson as the chaos night, just on a product surface instead of a test harness. The agent can build a lot. It can also be confidently wrong about an integration seam that only shows up when a person uses the thing.

What I am doing with that

I still rate Fable 5 extremely highly. Especially where the job is judgement, ambiguity, or a nasty recovery. Previously I would have centred essentially all serious autonomous work around Fable. I don't think that was foolish. The overnight feature work I have already written about is still the high-water mark for leaving a well-specified plan and coming back to a preview.

Grok 4.6 now looks close enough, in the actual engineering workflow I run, that other things matter much more than they used to. Sustained autonomous execution. Concurrency. How much inference I have left in the week. What it costs me in correction after the preview. What the subscription is actually buying.

I'm not going to invent a percentage. I don't have a notebook that says Grok is some fraction of Fable, and I wouldn't trust one if I did. What I have is a change in my own behaviour. I am increasingly inclined to give Grok the high-volume autonomous engineering, the nights with a contract and a test estate, and to keep Fable, or whatever is currently strongest at the ugly cases, for the jobs that are genuinely ambiguous, stalled, particularly difficult, or that need a second opinion from outside the first model's family. That change is more interesting to me than another gap on someone else's index.

I first tested this through the $30 SuperGrok plan. By the end of the concurrent Telemetry plus Jump Planner experiment, the weekly usage meter was around 95%. There was still a reset available. I have also been chewing through a substantial Claude allowance in the same window, which is part of why this suddenly matters. The meter is not an API bill and I am not inferring a token quota from a percentage bar. It told me two things at once. It delivered much more useful work than I expected for $30. And the workflow I now want to run may also be large enough that ordinary consumer allowances become the thing that runs out first.

I'm not going to recommend a tier. Those change. The point is simpler. Once two models are close enough on the work you actually do, you start caring more about stamina, concurrency and remaining allowance than about which launch video you watched.

So yeah. I did not expect to be writing this. I also did not expect to leave two Grok sessions on one machine and come back to a shipped telemetry night and a Jump Planner preview with one embarrassing right-click bug.

Related Posts

grok 4.6 grok build ai coding agents overnight autonomous runs claude fable 5 eve frontier software engineering subscription economics