▶ Article reader Listen + reading controls ⌄

LISTEN + READ YOUR WAY

Article reader

Preparing the reader…

▶ Play article ← → Stop

0:00 0:00

Speed 0.75× 1× 1.25× 1.5× 1.75×

Reading settings

Typeface Field Notes Atkinson Hyperlegible Lexend OpenDyslexic

Text size

A−

100%

A+

Reading surface Field Notes dark Paper light Warm sepia High contrast Text spacing Standard Comfortable

Reset reading preferences

Stable model access is part of the control plane

OpenAI has made the Generative Pre-trained Transformer 4 (GPT-4) application programming interface generally available to existing paying developers and announced a retirement path for several older completion and embedding models. The two developments belong together. Production access is not only about opening capacity; it is about managing change.

When an external model becomes part of an application, version stability and migration become product concerns.

A stable endpoint can contain a changing capability

Application programming interfaces (APIs) give software teams a durable way to call a service. Generative artificial intelligence (AI) complicates the usual expectation of compatibility. A request may remain technically valid while a new model changes tone, refusal behavior, factual performance, latency, or cost.

That means interface compatibility is necessary but insufficient. Teams also need behavioral compatibility for the task they support.

OpenAI's use of model snapshots and explicit deprecation notices provides useful mechanisms. The customer still needs a local process for deciding when to pin a version, when to adopt an update, and how to prove that the change is acceptable.

Model lifecycle belongs in architecture

A model version should be treated as a managed configuration item. The application should record which version produced an output and which prompt, retrieval configuration, tool definitions, and safety controls surrounded it.

Without that record, an incident becomes difficult to reconstruct. The team may know the application was “using GPT-4” but not which behavior, configuration, or data path was active at the time.

Configuration management is well-established in systems engineering because complex systems fail through combinations and changes, not only broken components. The same discipline applies here. A model upgrade is not a vendor housekeeping event; it is a change to the system baseline.

Every migration needs a representative test set

The retirement of older models will force some applications to migrate. Teams should resist treating the recommended replacement as a drop-in decision. They need evidence from their own workload.

A migration suite should include:

• frequent, ordinary cases;
• rare cases with high consequences;
• adversarial and ambiguous inputs;
• cases where the correct behavior is refusal or escalation;
• examples from different user and data populations;
• latency and cost under realistic load; and
• known historical failures.

Compare not only aggregate scores but the identity of failures. A replacement can improve the average and become worse on the cases that matter most.

The National Institute of Standards and Technology (NIST) Artificial Intelligence Risk Management Framework emphasizes ongoing monitoring and risk management across the lifecycle. Model migration is one of the clearest triggers for renewed measurement.

Build a control plane above providers

Organizations using models in several products should provide common services for model selection, access, telemetry, evaluation, and policy. This control plane can:

1. route approved applications to approved model versions;
2. manage credentials and data restrictions;
3. capture cost, latency, and version metadata;
4. run regression evaluations before a rollout;
5. stage migrations and support rollback; and
6. identify every consumer of a retiring model.

The goal is not to hide providers completely. Important differences must remain visible. The goal is to prevent every application team from inventing lifecycle management independently.

Stability is an organizational capability

General availability signals that a service is ready for broader production use. It does not promise that the capability will stop evolving. In artificial intelligence, change is part of the product.

Organizations will be resilient when they can observe that change, compare it with a known baseline, and migrate deliberately. Stable access is not the absence of model updates. It is the presence of a control plane strong enough to absorb them without losing evidence or surprising the people who depend on the application.

Sources and research trail

• OpenAI, “GPT-4 API General Availability and Deprecation of Older Models” (July 6, 2023).
• OpenAI, “GPT-4” (March 14, 2023).
• National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0) (2023).
• National Institute of Standards and Technology, Security and Privacy Controls for Information Systems and Organizations (2020).
• Amershi et al., “Software Engineering for Machine Learning” (2019).