On 7 August, OpenAI launched GPT-5 – and with it, quietly retired the menu of older models that hundreds of millions of people had built habits around. GPT-4o, the reliable daily driver for most ChatGPT users, vanished overnight, replaced by an automatic router that decides on your behalf which flavour of GPT-5 answers each request.
The backlash was loud enough that within about a day, 4o was restored for paying subscribers, and the company spent the following week adjusting the rollout in public.
There will be plenty of commentary about what this means for OpenAI. More useful for the rest of us: for one week in August, every organisation on the planet got to observe – free of charge, on someone else's product – exactly what happens when a critical tool changes under a workforce without warning. Worth debriefing like the incident exercise it accidentally was.
Lesson one: you don't control the toolsLink to this section
The uncomfortable core of it: a vendor changed the behaviour of a tool embedded in thousands of daily workflows, globally, overnight, and no amount of internal change-advisory process could have prevented it.
If parts of your operation quietly depend on a consumer AI subscription behaving the way it behaved yesterday, that's an operational dependency with no contract behind it. You wouldn't accept that for your CRM.
The mitigations are ordinary once you name the problem: enterprise agreements with deprecation notice periods for anything that matters; API access with version pinning where a process (not just a person) depends on model behaviour; and an honest inventory of which workflows lean on which tool – which most organisations discover they can't produce.
Lesson two: recipe training just expiredLink to this section
Here's the part closest to our day job, and the starkest split we saw.
People whose AI skill was a memorised recipe – this model, this menu, these magic words – were beached on Friday morning. The buttons had moved and the model behaved differently, so, functionally, they'd never been trained at all.
People who'd learned the transferable layer – how to decompose a task, give context, specify output, and verify what comes back – grumbled for an hour and adapted by lunch. Different model, same craft.
Train the judgement and the method, and the vendor can reshuffle the menu all they like. Train the menu, and every product launch is a retraining bill.
This has always been the argument against tool-specific click-here training; GPT-5 week just ran the controlled experiment at planetary scale. It's also why our courses drill task structure and verification on whatever model is in front of us, rather than worshipping any one tool.
Lesson three: the router quietly changed an assumptionLink to this section
GPT-5's design bakes in something subtler: an automatic router decides, per request, which underlying variant you get – quick and cheap, or slow and thorough. You don't choose; mostly, you don't know.
For casual use, fine. But plenty of teams built quiet assumptions on model consistency: the same prompt template producing the same shape of output for a report, a classification, a summary that feeds something downstream. "Which model answered?" now has a probabilistic answer, and output consistency is no longer something to assume – it's something to check, or to buy explicitly via pinned API versions.
There's a policy wrinkle too: if your risk assessment approved "GPT-4o for these tasks", what exactly is approved now? Write AI policy at the level of provider, product tier, and data class – not model nicknames that may not survive the next keynote.
Lesson four: attachment is real, plan for itLink to this section
The loudest surprise of the week wasn't technical: a meaningful number of users grieved 4o – its tone, its familiarity – with an intensity nobody's change plan anticipated. Whatever one makes of that, the workplace translation is mundane and actionable: people build relationships with their tools, and a swap-out has morale costs that "the new one benchmarks better" doesn't address. Communicate early, run parallel where possible, and let people voice the friction.
The drill to run before the next launchLink to this section
- List the workflows that would hurt if your main AI tool changed behaviour tomorrow. That list is your dependency inventory.
- For each: does it rest on a consumer subscription, or a contract with notice terms? Move the load-bearing ones.
- Check your training. If it teaches menus and magic phrases, it has a shelf life measured in keynotes. Ask for judgement-based training – from us or anyone.
- Write model changes into your comms playbook like any other vendor change: who assesses, who tells staff, who updates the policy.
There will be a next time – every lab has more launches queued, and "models change under you" is now simply weather. August's storm was survivable and instructive. The organisations that treat it as a drill report, rather than a news item, will be the ones bored by the next one.