September brought two pieces of news that at first sight have little to do with each other. On 3 September OpenAI released GPT-6 Astra, and on 22 September GPT-6 Sol and Luna followed at prices half as high as their predecessors. Sol costs two US dollars per million input tokens and ten US dollars per million output tokens. And today, on 24 September, the Sora interface for video generation is being shut down, six months after the announcement in March. Both events lead to the same conclusion: the model layer moves faster than the business cases and architectures built on it.
What the price drop means for business cases
Many business cases for AI applications were calculated in spring with the token prices of that time. Part of their assumptions is now outdated, and in both directions. Use cases shelved as too expensive, such as the complete analysis of large document collections, may now be economical. At the same time, applications whose value lay mainly in cheap access to model performance lose their edge, because everyone now has that access.
The proportion matters here. In most productive applications, model costs are not the largest cost block. Integration, review, operations and enablement dominate, and a price cut changes nothing about them. A business case therefore becomes robust when it does not treat model costs as a fixed figure but calculates with a range and shows at which price the decision would reverse. That sensitivity belongs in every proposal going up for approval today.
Deprecations are part of normal operations
The discontinuation of Sora is not an isolated case but a particularly visible example of a regular process. Vendors withdraw models, versions and interfaces when they do not pay off or are replaced by successors. For Sora, the app was discontinued first in April, and the interface follows today. Anyone who built a product or an internal process on it had to migrate within six months. That is a comparatively generous period, and still it is too short for some organisations, because nobody knew everywhere the interface was in use.
This leads to a simple requirement: for every productive application it must be known which model in which version it runs on and until when that version is guaranteed. Very few companies maintain such a register, because model choice has so far been regarded as a technical detail of project teams. As the number of productive applications grows, it becomes a question of operational resilience.
Replaceability is an architecture decision
Whether a model change takes days or months is decided not at the time of the change but at the time of building. Three elements make the difference. An intermediate layer between application and model, so that the change does not have to be made in every application separately. Prompts and configurations that are not tailored to the peculiarities of one vendor. And above all, a dedicated set of test cases per application, with inputs and expected results, against which a new model can be checked. This test set is the real asset, because it turns the question of whether a change is possible from an assumption into a measurement.
The new model families with several price tiers also make a division of labour sensible that many companies do not yet use. Tasks with high demands on judgement run on the most capable model, tasks with high volume and clear structure on an inexpensive one. This split lowers costs far more than any price negotiation. It does, however, require the same precondition as switching vendors: the ability to measure the quality of a model for a specific task.
What procurement and contracts must deliver
The price development calls long-term purchase commitments into question. Anyone who agreed a multi-year minimum volume at fixed prices in spring may now be paying twice the market price. Contracts for model services therefore need price adjustment clauses or short terms for price commitments. Minimum notice periods for deprecations also belong in the contract, with a length that allows an own migration including testing.
A third point is almost always overlooked: taking along what is created in the course of use. Adapted models, vector databases and stored configurations should be releasable in a format usable with another vendor. Without this commitment, a lock-in arises that works not through the contract but through the effort of rebuilding, and that is usually stronger.
Conclusion and recommendation
The model layer is becoming cheaper and less stable at the same time, and both point to the same answer. For the next ninety days we recommend three steps. First, recalculate the most important business cases with current prices and a price range, and reassess shelved use cases. Second, build a register of all model dependencies with version and guaranteed lifetime. Third, create a test set for every productive application that makes a model change measurable, and review existing contracts for price commitment, deprecation notice periods and data portability.
ECODYNAMICS helps companies align their AI landscape with this mobility. In AI Executive Advisory we reassess business cases and platform decisions, and with AI Solutions & Engineering we build the intermediate layer and the test sets that make a change plannable. If contracts for model services are currently being negotiated or renewed at your organisation, talk to us before prices are locked in for the coming years.