What Theo Built with GPT-5.6 During Six Weeks of Early Access

I had early access to GPT-5.6 for roughly six weeks and pushed it much harder than I normally would. Depending on the estimate, the inference I used was equivalent to $180,000–$240,000. That is an estimated value of usage, not a claim that I paid an API bill of that size.

This is a tour of what I built, not a complete review. I had not seen the broader reaction, tested Luna or Terra, used ChatGPT or Pro, or tried the newer ultra and max options during this early-access period. Comparisons and pricing need separate treatment.

I had been skeptical of computer use: an agent taking screenshots and clicking through interfaces seemed slow and unreliable. GPT-5.6 changed my experience with browser tasks, such as navigating a dashboard or making a change in Notion. That is a personal observation, not a guarantee that every action succeeds.

OpenAI did not pay me for this coverage. I paid for my subscription, and the early-access allowance enabled an unusual scale of experimentation. I do not think the roughly $200,000 inference equivalent is a realistic monthly pattern to recommend to anyone.

I worked across 67 projects, sometimes setting a broad goal and sometimes steering through many iterations. I also used the model and SSH computer use to distribute a central configuration across my machines. The range matters: these were experiments with varying amounts of human direction, not a controlled benchmark.

Compared with my experience of 5.5, 5.6 seemed better at understanding intent and staying with a task. Some runs went for more than 20 hours without my using the goal feature. Long duration alone does not prove correctness, but the persistence changed the kinds of projects I was willing to attempt.

Lakebed was one of the largest projects. The displayed audit estimates roughly $30,000 at fast-mode API rates for that work; the actual economics depend on the product and conditions, so it should not be read as a current subscription entitlement. I used the model to break large JavaScript files into a more manageable TypeScript project.

It also helped build CI, preview and release workflows, artifact storage, file uploads and deployment refreshes. CLI authentication and access controls required substantial work, with me providing some direction about the desired user experience. The report on screen also notes that some passing local suites missed adversarial cases.

I used it to harden the database and review file-storage contracts, identifiers and MIME policy. For runtime isolation it researched alternatives and produced plans; pricing and quota work also included planning rather than a finished billing system. I preferred other models for some of that analysis.

It recovered and reviewed pull requests using multiple threads, and assisted with an open-source launch audit. Earlier demonstrations that I made look like 5.5 were actually using 5.6; I apologize for that. When I later tried similar subagent prompts with 5.5, my experience was much less successful.

For T3 Code, which Julius and I use to manage agents across devices, I pushed mobile development especially hard. I asked for two separate native rewrites of a React Native app and found both surprisingly functional, with each taking around two to four hours in my tests.

The model could use a simulator as part of the iteration loop. I also built a computer-use loop for T3 Code, although Julius subsequently made a better version and I did not submit mine. Other work included reviewing app-server primitives and planning a computer switcher that was not shipped.

I rebuilt the marketing site with its help. Front-end output is not perfect, but I think it can look good with the right direction. I also used subagents to triage T3 Code pull requests and later set up a daily Hermes automation to help me stay on top of them.

I then tried larger rewrites. For a Rust version of Hermes Agent, I had the model examine our usage history to identify the features we actually used. The resulting prototype handled a useful subset, including responding in a separate channel, creating threads and using skills.

The Rust agent used roughly 15 MB of memory in my example, but it was not feature-complete with Hermes and needed more work before I could rely on it daily. I estimated around $13,000 at fast-mode rates, perhaps $5,000–$7,000 without fast mode; these are estimates, not bills.

I also attempted to rewrite the Go-based TypeScript implementation in Rust out of curiosity. I initially describe a working transpiler and a speed comparison, but the important qualification is that the verified no-check transpilation covered a deliberately narrow five-file corpus. That is not a complete TypeScript compiler.

The prototype had roughly 195,000 lines of Rust across 29 crates, but type checking remained incomplete and tests were failing. A separate model review characterized it as a broad prototype with only a small verified slice and far from shippable. I had not yet reconciled all the work left in a stash.

For a developer-folder synchronization idea, I set a long-running goal and discovered it had consumed 71.2 billion tokens, estimated at about $91,000 at fast-mode rates. I had not yet opened or deployed the project, so I could not say whether it worked. The displayed report similarly says production proof was incomplete.

A friend at PlanetScale alerted me that the agent had registered for the service while working on the project. That surprised me and illustrates how far an autonomous run can go when given access. I planned to inspect the result and deployment later rather than claim success from the logs alone.

Managing my machines led to another experiment: a bootable recovery drive with coding tools already configured. I wanted an easier way to boot a machine, connect it to the network and get remote help when a Linux installation broke. An agent helped set up that drive.

One machine had broken boot configuration after I removed an SSD. At first the model hallucinated BIOS options that were not there. I gave it access through a remote KVM, and after failed attempts it rebooted, reached a GRUB shell, booted the machine and repaired the boot setup.

That repair impressed me because the task normally demands research, patience and risk tolerance. It also demonstrates that the model can be wrong before it succeeds. I now keep a fleet repository describing my machines and their configurations so an agent can use that context when setting up another one.

The model helped overhaul Skatebench, although I noticed a bug in its token-spend reporting and did not trust the displayed usage numbers. I also used browser automation to check shopping deals and create tracking links. It saved manual clicking, but the copy it wrote was bad enough that I discarded it.

It built a terminal token tracker and gathered data from my fleet, but I disliked its visual design and rebuilt the UI with another model. The model is more steerable than before, in my experience, yet it does not automatically produce the front-end design I want.

I also found the generated 3D version of Fish Slop. It made the environment, textures and assets, and with guidance improved the controls. The shooting controls and some creature models were still poor; the result was not something I would ship, even though the progress is interesting.

Other experiments included a minimal service alternative, a way to use Codex authentication with Claude Code workflows, a network presence display and improvements to my HTML plan service. I note that Fable did most of the recent cleanup on the latter, so not every change shown should be credited to 5.6.

I wanted to show the concrete work before offering a broader review. These experiments made me excited to think bigger: the model often persisted with complex tasks with less steering than I needed for 5.5. The results still varied, and a large output or long run was not the same as a verified, finished product.