[flagged]
Migrating a production AI agent to GPT-5.6: 2.2x faster, 27% cheaper
61–70 of 144 posts
Re: Migrating a production AI agent to GPT-5.6: 2.2x faster, 27% cheaper
#62I catch a lot of issues on the technical writing side.
Re: Migrating a production AI agent to GPT-5.6: 2.2x faster, 27% cheaper
#63> 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 L…
Can we get over the detective work about if the text was written by LLM or not in 2026 already ? This is a lost cause, and we could instead focus on substance over syntax.
Re: Migrating a production AI agent to GPT-5.6: 2.2x faster, 27% cheaper
#64Earlier quoted context omitted.
Can we get over the detective work about if the text was written by LLM or not in 2026 already ? This is a lost cause, and we could instead focus on substance over syntax.
Not OP but my frustrations come from it being impossible to ignore and outright distracting. I've found the same thing showing with Claude-coded/designed front ends that overuse the same semi-monospaced fonts, Blue/Yellow/Red palette and rounded corner borders. It isn't that it is bad , but it often isn't fit for purpose. You're right it wont change anything, but authors shouldn't be surprised when people who care ab…
Maybe if instead we stopped engaging they would wonder why
Re: Migrating a production AI agent to GPT-5.6: 2.2x faster, 27% cheaper
#65> 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).
Re: Migrating a production AI agent to GPT-5.6: 2.2x faster, 27% cheaper
#66We 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 fo…
What SDK are you using? Or is it custom?
Re: Migrating a production AI agent to GPT-5.6: 2.2x faster, 27% cheaper
#67We 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 fo…
the article is literally about the model upgrade not being a one liner
Re: Migrating a production AI agent to GPT-5.6: 2.2x faster, 27% cheaper
#68Migrating my workflow to Reasonix with cache hits on Deepseek make requests practically free, and that's on unsubsidized American providers.
What's your config, how does it compare to pi
Re: Migrating a production AI agent to GPT-5.6: 2.2x faster, 27% cheaper
#69> 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…
Modern frontier models, including Fable/Opus and 5.6, are often very loose with tool calls, and often don’t follow your schema precisely.
For example, see this post for Claude models hallucinating properties for an edit/replace tool call in Pi: https://lucumr.pocoo.org/about/
I suspect some part of this comes from the noticed intelligence degradation when you do constrained decoding. Yes, you’re guaranteed schema validation, but you lose a lot of intelligence. It’s fine if you just want a classifier, a summary, a prompt enhancement, etc; but I’d be careful in agentic loops.
Harnesses like Claude Code do a lot of preprocessing, repairing, cleaning, etc; as the blog post shows. You usually don’t see it.
In practice it’s easier and better to just make your harness “looser” and work better with the model (they’re coming out every month or two anyway, each with their own idiosyncrasies) than to assume and force perfect correctness.
Welcome to vibe applied AI ;)
Re: Migrating a production AI agent to GPT-5.6: 2.2x faster, 27% cheaper
#70We 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.