Migrating a production AI agent to GPT-5.6: 2.2x faster, 27% cheaper

blfr

> Ploy’s agent builds and edits real marketing websites. It plans a page, reads the codebase, writes components, generates imagery, screenshots its own work, and decides when it’s done. That job description sets a very high bar for a model, and we test every frontier release against it. For the four months Opus held the default slot (first Opus 4.7, then 4.8), nothing we tested beat it. Well, unlike OP I haven't run a rigorous test, but I still would expect Fable to be significantly better at building marketing websites than Opus. It sure is way better at building decks.

kristianp

> Numbers like that buy a model a real migration effort. Such a silly choice of words. I wish the human directing the LLM writing the article put some effort into rewriting the worst examples of LLM style. > But it did extremely well, and the promise was immediate and specific: builds finishing in less than half the wall-clock time, at 27% lower cost, scoring at or above our incumbent on completed work. The way the LLMs write (Claude perhaps?) With short phrases separated by colons, commas or full stops, is so poor and frustrating. There some good insights behind this article, so it's worth reading, for example below, but it isn't easy to read. > Earlier GPT models cached implicitly on partial prefix matches, which gave decent hit rates for free. GPT-5.6 dropped partial-prefix matching:

estebarb

But what users prefer? Given this is for marketing, which results produce more conversions? From the examples shown, personally I strongly preferred Claude Opus in all cases.

arikrahman

Migrating my workflow to Reasonix with cache hits on Deepseek make requests practically free, and that's on unsubsidized American providers.

bob1029

> we’ve made GPT 5.6 Sol the default model powering every Ploy workspace I would consider Luna for parts of the workload that touch actual tools. It is surprisingly capable and it runs fast. Sol is great at talking to the human and orchestration of agent calls, but it's just too expensive to use everywhere. You can get 5 Luna runs for the cost of 1 Sol run. Statistically speaking, going from one to five samples is a pretty big deal.

thiagoperes

We run a lot of varied, tiny, simple workflows that were previously running on 5.4-nano and mini. We transitioned them to 5.6 and noticed exactly this range of improvement across the board. In a few cases, we had improvements in classification. I think a lot of people miss that for many companies, a model upgrade like this is basically a one liner. Even if you have an amazing model router architecture (which we do for our golden flows), it’s just not worth it. Not to mention reliability and so on

redfather918

The cost reduction is impressive, but I think consistency matters even more for production agents. I'd be interested to know whether prompt engineering or tool-calling workflows had to change significantly.

desktopentree

I catch a lot of issues on the technical writing side.

lcampbell

> The fix that worked is a schema transform at the provider boundary. For OpenAI-family models only, we rewrite every optional property to be required but nullable, using anyOf: [T, null], which gives the model an explicit way to say “not using this.” I admit, I've only used a bastardized form of MCP, but this smells... wrong? It's not clear to me why the Typescript type definitions would have any influence on (what I presume is) JSONSchema being sent from the agent to the inference backend as part of the completion request. The MCP specification (which the OpenAI backend might not use, I don't know) has an explicit field to signify "optional" parameters in the JSONSchema; my read on this is there's a bug somewhere between the Typescript layer(??) and the generated tool description which is actually sent to the inference backend. It's possible the inference backend has changed from "generate valid tool responses" to "generate valid tool responses according to the JSON schema [where no parameters are optional]" but it's impossible to tell without seeing the actual requests sent to the inference backend (which I didn't see in TFA).

ianberdin

We at Playcode.io - a company similar to Ploy are still using Opus 4.6. "Why?" you might ask. Because GPT 5.6 Sol, while fast and pleasant to use, is essentially the same model as 5.5 wrapped in new marketing packaging, just to avoid losing ground to Anthropic. In practice, it's the same quality: it generates the same garbage, tons of code, and can never solve even a single complex task. We simply don't trust it to write code for clients that they'll end up throwing away anyway. "Then why not Opus 4.8?" you might ask. Well, because Opus 4.8 and 4.7 are just another lie, a price hike with no actual quality improvement. That's why at Playcode, we give our clients the best possible quality/price - which is Opus 4.6. Regardless of what people write in articles like this.

htlemur_bobby

I found Claude to be better for the first prototype. It was more likely to come up with something fast. But it kept lying and claiming it did world class work and it was just hardcoding response by the end. I found GPT never lied to me.