GPT-5.6, 48 hours and 4.5 billion metered tokens later

OpenAI released GPT-5.6 across ChatGPT, Codex and the API on 9 July. I did not have preview access. In the 47 hours and 54 minutes from my first GPT-5.6 Codex task to measuring this, ccusage counted 4,490,888,951 GPT-5.6 Sol tokens.

That number needs a caveat immediately. About 4.35 billion were cached input tokens. The remaining count was roughly 127.5 million uncached input tokens and 12.4 million output tokens. This is 4.5 billion metered tokens, not 4.5 billion newly generated tokens. It is local ccusage accounting filtered to the observed dates and model, so it may not map perfectly to every hidden or system token.

It is still a reasonable measure of how hard I have leaned on it. In those first 48 hours I used GPT-5.6 to make 32 browser artefacts, research and write a fairly enormous guide to free compute, audit and rebuild substantial parts of Crate Lynx, consolidate seven repositories into one website, and make a small animated lynx called Patch.

The thing that surprised me was not that it could make a code change. We are well beyond the age where these systems being capable of a small change within one repository is especially interesting. What feels different is how long GPT-5.6 will stay on a difficult piece of work, and how large the unit of work can become before it loses the thread.

Researching and making things

One of my first GPT-5.6 projects was not an immediate success. I moved LLM Choice over to Sol, asked it to produce twelve experiments, and got twelve polished but mostly shallow artefacts. Most took about five minutes. The stronger model had made the first throughput-shaped prompt faster and prettier without making the underlying ideas much more interesting.

I changed the prompt to protect ambition and conceptual depth, then ran another twenty experiments. Across the two batches, GPT-5.6 produced 32 artefacts in 458.4 aggregate run-minutes. The second batch contained much more substantial simulations and instruments, but it also took far longer and had a different prompt, review process and level of curation. I wrote about that separately in GPT-5.6 needed a more ambitious prompt. It was not a controlled 5.5 versus 5.6 test. It was evidence that the ceiling moved a long way once the brief gave the model somewhere useful to go.

The July Free Compute guide tested a different kind of work. I had Codex do the research as well as write the post. It split the research across primary-source lanes, brought them back into one matrix, and then went through the normal separate source-fidelity review.

The working research totalled 10,754 words. The finished guide was 4,813 words with 133 unique external links, and the complete writing run took about 58 minutes from starting it to publication. More importantly, it handled contradictions rather than just collecting offers. It found conflicting official Oracle figures and kept the smaller allowance, removed an IBM product that had been retired, caught an imminent Deno Deploy closure, and separated several things that all get lazily described as free compute but have completely different limits.

I think it did a really really good job of doing the research and consolidating everything. That matters because research-heavy writing is not just a longer version of code generation. The useful bit was deciding which claims survived contact with the sources.

The second audit went deeper

The clearest comparison with GPT-5.5 came from Crate Lynx. I had already run a broad audit and implemented work from it. That earlier audit was useful. It just did not go as deep. This was still not a controlled model comparison: the codebase had changed, and the new audit used a broader prompt and stronger browser and PostgreSQL verification.

The fresh GPT-5.6 audit found significantly more beneath the apparently healthy application. Invalid ISRC values such as N/A could become perfect, high-confidence music matches. Ordinary proposal approvals could create contradictory final links. A Review link could point at one exact proposal while the destination ignored it and showed only the first 50 of 646 proposals. The PostgreSQL test fixture replaced its password with literal ***, so 21 integration tests skipped when PostgreSQL was unavailable and failed during setup when it was available. A supposedly lightweight shell summary made 102 SQL statements for 100 suggestions.

These were not speculative code-review comments. The audit reproduced the strongest failures against the application and database while the existing test suite was still passing.

The remediation that followed changed 114 files across ten commits. It introduced a guarded database migration, centralised link mutation and locking, fixed canonical ISRC handling, completed broken workflows, moved library queries to the server, rebuilt substantial mobile behaviour, and added real PostgreSQL, browser and accessibility coverage. The final verification passed 460 backend tests, 293 frontend tests, and the browser checks.

The production migration then found 22 real legacy conflicts and stopped instead of choosing winners. After a backup and an auditable repair, it completed with no remaining exact or equivalence conflicts. The model had not merely generated a large diff. It had carried a data invariant from audit, through implementation and testing, into the awkward state of the real database.

The repository stopped being the unit of work

Crate Lynx was still one application. The BillieM website consolidation was the point where the scale felt genuinely different.

The public site had spread across seven repositories and several subdomains: this blog, LLM Choice, Local Choice, the site graph, Games, Account and Payments. They had separate build systems and deployment ownership, plus shared chrome snapshots, per-origin crawl files and cross-repository triggers trying to hold the result together.

GPT-5.6 first audited that arrangement, including the SEO and migration risk, then carried the consolidation through as one task. The result is one private monorepo, one public origin, one production Worker, one preview Worker, three separate databases, one sitemap and one robots file. The composed site contains 195 HTML routes and 97 indexable URLs. The old subdomains now redirect directly to the corresponding apex paths, with their paths and query strings preserved, and the previous deployments remain available for rollback.

That task crossed architecture, Go, Python, TypeScript, Workers, D1 migrations, redirects, SEO, build composition, browser checks and live deployment. I do not think that kind of wide, cross-repository change was realistically possible for me with the previous models. There was too much state to hold and too many boundaries to keep coherent.

The biggest difference I have noticed with 5.6, at least using Sol at Extra High and Ultra, is that it seems much happier doing really really long-running tasks in one run. You send it off and it goes and it goes and it goes. Then it goes for a really long time and comes back with the work done.

That does not mean it required no steering. The Choice experiments improved because I changed the brief. The website consolidation started with an architecture decision. The production migrations had approval boundaries, backups and verification. Once those decisions existed, the model kept working through an amount of connected implementation that would previously have needed to be split into much smaller pieces.

Patch, and where Ultra got stuck

The personal pet is a much smaller example, but the pet is really cute.

The first attempt used GPT-5.6 Sol at Ultra and ran for about two hours and 23 minutes. It became stuck trying to converge on the directional sprite patterns: poses landed in the wrong quadrants, directions flipped, and the final blind review still read a left-facing pose as right-facing. It never installed the pet.

A later Extra High run used a simpler lynx design, isolated the image work more tightly, and had the lessons from that failed attempt. It completed and installed Patch in about 75 minutes. That is not a controlled argument that Extra High is better than Ultra. The task and process changed. It is a useful warning that more effort can still become an expensive loop rather than a better answer.

With GPT-5.5, my working assumption was that it was worth using Extra High for nearly everything because it did not take that much longer. After two days with GPT-5.6, I am less sure that one default will make sense. The higher effort levels appear to go much deeper than they did in the previous family, but the distance between effort levels may matter more too.

I have only used Sol at Extra High and Ultra so far. The next thing I want to do is explore lower Sol effort levels, then Terra and Luna. I want to know how depth, runtime and reliability move across those choices, and whether the occasional Ultra convergence loop becomes more or less common.

For now, 48 hours produced two posts, 32 experiments, two very large pieces of application and infrastructure work, and one waving lynx. The 4.5 billion metered tokens are funny, but the scale of the completed work is the bit I did not expect.