OpenAI Evals Platform, Agent Builder, and Reusable Prompts Deprecated: November 2026 Shutdown

On June 3, 2026, OpenAI added three platform-level deprecations to its official deprecation tracker, all with a common shutdown date of November 30, 2026: the Evals Platform, the Agent Builder, and the Reusable Prompts (v1/prompts API). Unlike model-ID deprecations — which typically require a line-change in a config — these are infrastructure retirements that affect how teams manage prompts centrally, evaluate model outputs at scale, and build Responses API agents without writing SDK code. This post breaks down each retirement and maps out what moves into the routing and gateway layer once OpenAI stops hosting it.

What OpenAI deprecated on June 3, 2026

The openai evals platform deprecation covers three distinct products:

Evals Platform: OpenAI's hosted eval runner — create, run, and score LLM evaluation suites from the dashboard or via the Evals API. Goes read-only October 31; all eval runs stop November 30.

Agent Builder: The no-code/low-code dashboard UI for composing Responses API agents (tool configuration, instruction editing, testing). The underlying Responses API itself is not deprecated; only the Builder UI and its saved-agent objects are being retired.

Reusable Prompts (v1/prompts): The POST /v1/prompts endpoint that lets teams store and version prompt templates server-side under OpenAI's infrastructure. Any application that calls /v1/prompts to retrieve a stored template at inference time breaks after November 30.

Why the openai evals platform deprecation matters for routing operators

Each of the three retirements shifts responsibility to the operator layer in a different way.

v1/prompts API removal and gateway-side prompt management

The Reusable Prompts API was the simplest abstraction: call OpenAI, get back your stored prompt, inject into the request. After shutdown, teams that relied on it for centralized prompt versioning — especially multi-team setups where different product lines share a prompt library — need somewhere else to store and serve those templates at inference time.

The natural home is the routing and gateway layer. An AI gateway that intercepts outbound requests can inject prompt templates from a versioned store before the request leaves your infrastructure. This keeps prompt assets portable: the same template works regardless of whether the downstream model is OpenAI, Anthropic, or a domestic provider like DashScope. For teams already using multi-provider routing for fallback or cost routing, adding prompt injection at the gateway adds no new hop and improves portability.

The secondary benefit: prompt versioning in your own infrastructure is auditable. OpenAI's hosted prompt store was a black box for compliance purposes; a gateway-side store is a first-class artifact in your CI/CD pipeline.

Evals Platform shutdown and routing-layer observability

The Evals Platform served a dual purpose: automated benchmarking before deployment and ongoing quality monitoring in production. Its shutdown doesn't invalidate the need — it moves ownership.

The most routing-relevant consequence is online eval coverage. Teams running Evals to catch regressions when switching model versions now need to replicate that signal elsewhere. Two approaches map cleanly onto the routing layer:

1. Model comparison routing with shadow traffic: route a configurable percentage of live traffic to a candidate model in shadow mode, compare outputs against a reference model, and log discrepancies. No OpenAI-hosted eval infrastructure required.
2. Structured eval pipelines via Promptfoo or similar: run eval suites against TheRouter's /v1/chat/completions endpoint directly, exercising real fallback chains and provider selection logic rather than a single-model eval.

The long-tail goal — openai evals platform and agent builder shutdown november 2026 routing layer migration — resolves to a combination: move eval execution to an open framework, move eval routing (which model family do I evaluate?) to your gateway.

Agent Builder shutdown and SDK-based agent authoring

Agent Builder was a productivity tool, not a runtime dependency. Teams that used it to prototype tool-calling chains, instruction sets, and handoff flows will need to port those configurations to the Responses API SDK directly. The underlying Responses API (POST /v1/responses) is unaffected.

This is the least disruptive of the three retirements for teams already writing production agents in code. For teams that leaned heavily on the Builder UI for non-engineers to configure agents, the shutdown forces a process change: agent configuration now lives in version-controlled code, not a dashboard.

From a routing perspective, this makes agent configurations more portable by default. An agent defined in SDK code with explicit model IDs and fallback lists works identically through any OpenAI-compatible gateway; an agent that existed only as a Builder-saved object was implicitly locked to OpenAI infrastructure.

Migration checklist for the November 30 shutdown

Use this checklist to assess and prioritize before the October 31 read-only deadline for Evals:

1. Audit v1/prompts usage. Search your codebase and API logs for calls to /v1/prompts. For each found: identify the prompt ID, export the stored template, and decide on a replacement store (gateway-side injection, a secrets manager, or a dedicated prompt registry).

2. Export Evals configurations before October 31. The Evals Platform goes read-only October 31, 2026. Export all eval definitions, graders, and historical run data before that date. After October 31, you can read but not modify; after November 30, you can do neither.

3. Inventory Agent Builder saved agents. List all agents created in Agent Builder, download their instruction and tool configurations, and convert to Responses API SDK calls. Confirm each agent works end-to-end before November 30.

4. Choose an eval framework replacement. Promptfoo, LangSmith, and Braintrust all support OpenAI-compatible endpoints natively. If your routing setup uses multi-provider fallbacks, point the eval framework at the gateway endpoint rather than OpenAI directly so evals exercise the full routing path.

5. Set a hard internal deadline of October 15. The November 30 shutdown lands in late Q4, overlapping with many organizations' change-freeze windows. Internal freeze policies in October–November reduce the effective migration window. Target completion in the first half of October.

6. For v1/prompts specifically: test gateway-side prompt injection. If you move prompt storage to a gateway layer, validate that the injected prompt contents are stable across locales and model families — especially for teams routing to non-OpenAI providers where system prompt formatting conventions differ slightly.

Secondary keyword note: openai v1 prompts API migration at the gateway

The openai v1 prompts api migration gateway path is worth treating as a first-class architecture decision, not just a find-and-replace. Teams that centralized prompts in OpenAI's hosted store often did so because they needed a single source of truth across many services. Rebuilding that capability at the gateway layer — rather than scattering prompt strings back into individual application codebases — preserves the original intent while removing the OpenAI dependency.

A gateway-side prompt store also integrates naturally with multi-provider routing: when a provider experiences degraded quality or an outage, the fallback chain picks a different model, but the prompt template stays constant. The template is no longer entangled with a specific provider's infrastructure.

Timeline

The five months between now and shutdown is enough time to migrate cleanly if you start the audit now. The October 31 read-only gate for Evals is the forcing function — treat that as your internal soft deadline, not November 30.