Ploy's GPT-5.6 Migration Post Shows the Growth Play: Publish Your Internal Model-Switch Numbers, Not Just the Decision.

The play

Ploy migrated its production AI agent from Claude Opus 4.8 to GPT-5.6 Sol. Instead of a one-line changelog entry, it published a full engineering writeup with exact numbers.

That decision is the growth play.

What the numbers actually said

Ploy's agent "plans a page, reads the codebase, writes components, generates imagery, screenshots its own work, and decides when it's done." The post reported:

• Mean cost per completed build: $3.06 versus $2.22 — 27% cheaper
• Wall-clock time: 8 minutes versus 3 minutes 42 seconds — 2.2x faster
• Visual score: 0.936 versus 0.970

Why this traveled

A vague "we switched AI providers" post is forgettable. Ploy's post worked because it read like an honest engineering account, not a marketing update:

• It named the exact models: Claude Opus 4.8 and GPT-5.6 Sol
• It included the failure it hit, not just the win: a schema issue where GPT-5.6 invented values for unused tool parameters, causing "52-64% of file reads to return empty results"
• It included a caveat that cuts against the model it just adopted: GPT-5.6 "is very good at clean, modern, tightly-gridded layouts, but it tends to converge towards that look unless you steer it well"

That mix of a real win, a real bug, and a real limitation is what makes the piece credible to a technical audience, and credibility is what gets something shared past your own following.

The growth play to steal

1. Next time you make an internal infrastructure or vendor decision, write down the exact before/after numbers as you measure them, not after you've forgotten the specifics.

2. Publish the failure modes alongside the win. A post that's 100% good news reads like an ad; a post with a documented bug and its fix reads like a real account.

3. Name your tools and providers precisely instead of writing around them — vagueness signals you have something to hide or nothing specific to say.

4. Keep the caveats in the final draft. A single honest limitation makes every other number in the post more believable.

5. Publish while the topic is live — a new frontier model release, in Ploy's case — so people already searching for a comparison find your account of it.

Bottom line

Ploy's post isn't remarkable because the migration worked. It's remarkable because Ploy showed the receipts — cost, time, quality, and the bugs in between — instead of asserting the upgrade was better. That transparency is what turned routine infrastructure work into distribution.

Source: https://ploy.ai/blog/migrating-a-production-ai-agent-to-gpt-5-6