ai platform

OpenAI apps that don't fall over when the model you built on gets retired.

We build applications and agents on the OpenAI API and hook them up to your data and identity systems. We also keep an eye on OpenAI's deprecation schedule, because a retired model shouldn't be how you find out production is broken.

platform dossierOpenAI APIAI platform
Vendor
OpenAI
Latest general-purpose models
GPT-6.1 Terra (26 Oct 2026), GPT-6.1 Sol (29 Sep 2026), GPT-6 Astra (3 Sep 2026)
Next shutdown
Evals, Agent Builder, v1/prompts API: 30 Nov 2026
Then
GPT Image 1 Mini, 1.5: 1 Dec. GPT-5, o3: 11 Dec. GPT-4o, GPT-4.1: 14 Jan 2027
release watch
  • GPT-6.1 Terra released26 Oct 2026
  • Legacy GPT snapshots shut down23 Oct 2026
connects with
in short·15-second read

Cohash builds production apps on the OpenAI Responses and Agents APIs and keeps them running through OpenAI's shutdowns.

Evals, Agent Builder and v1/prompts go on 30 November 2026, GPT-5 and o3 on 11 December, then GPT-4o and GPT-4.1 on 14 January 2027. Check which model IDs your code calls now.

you probably need this if
  • Your code still calls a model on OpenAI's deprecations page. On the shutdown date those calls start failing, and you find out from the errors.
  • An internal tool still runs on the Assistants API and nobody has moved it to Responses yet.
  • One API key is shared by several teams and nobody has set a spend limit.
terms on this page Agent BuilderdefinitionOpenAI's drag-and-drop canvas for agent workflows. Someone publishes a workflow and gets an ID back. Your chat or app has been calling that ID ever since.explained in a field note →
Ask an engineer facts checked 2026-11-08
how it runs
  1. 01Usage and model inventory
  2. 02Evaluation set first
  3. 03Migrate and add tools
  4. 04Projects, keys and limits
  5. 05Monitor and hand over
you keep
  • A list of the model IDs your code actually calls, each with its shutdown date, so nobody learns about one from a failed call.
  • We write a test set that scores every model or prompt change, so nobody argues from gut feel.
  • Saved prompt objects moved into your repo before v1/prompts shuts down, so nothing still calls it on the day.
+ 3 more documents
who does it
AI engineer (OpenAI API, Agents SDK)LLM evaluation engineerRetrieval and RAG engineer
platforms
openai-api · release timeline
  1. 26 Aug 2026 Assistants API shut down The Assistants API is gone. OpenAI points people to the Responses and Conversations APIs, and any thread or assistant logic left in old code has to be rebuilt there.
  2. 03 Sep 2026 GPT-6 family Astra came first, and OpenAI still calls it its most capable model. Sol and Luna followed on 22 September, then 6.1 Sol on 29 September, cheaper than Astra. Moving to Astra means some code changes: it won't take a custom temperature or top_p, and tool calls only work through the Responses API. Chat Completions code that calls tools has to move first.
  3. 10 Sep 2026 Agents API in public beta The Agents API opened as a public beta, and computer use was added on 29 September. It's still beta, so keep production paths on stable APIs and put agent runs behind a flag you can switch off.
  4. 16 Oct 2026 Agents API and GPT-Live updates The Agents API got an Ultrafast mode, set through agent.service_tier. On the voice side, GPT-Live can now call the Decisions API natively, and every API customer can build a custom voice from a text prompt. Both are new, so test them on a side path before production traffic goes near them.
  5. 23 Oct 2026 Legacy GPT snapshots shut down Calls to gpt-3.5-turbo, gpt-4, gpt-4-turbo, gpt-4.1-nano, o1, o1-pro, o3-mini and o4-mini now fail, and fine-tunes built on them went with them. Anything still pointing at those IDs is already broken. Check your error logs before you check the code.
  6. 26 Oct 2026 GPT-6.1 Terra released OpenAI describes Terra as fast and efficient, and says it suits visual reasoning, computer use and writing. If an older small model does your high-volume steps, run Terra through the same evals now, because GPT-5 and GPT-4o are both going away soon.
  7. today · Nov 09, 2026
  8. 30 Nov 2026ahead Next: Evals, reusable prompts, Agent Builder Your evals went read-only on 31 October 2026, and on 30 November the Evals dashboard and API are switched off. The v1/prompts API and Agent Builder go that day too. Move prompt text into your code before then. OpenAI points people to Promptfoo for evals, and to the Agents SDK or ChatGPT Workspace Agents for Agent Builder flows, so someone still has to rebuild them.
  9. 11 Dec 2026ahead Then: GPT-5, GPT-4o and fine-tuning Three cut-offs land within five weeks. The first GPT-5 snapshots, o3 and o3-pro go on 11 December 2026. From 6 January 2027 nobody, existing customers included, can start a fine-tuning job. The dated GPT-4o and GPT-4.1 snapshots, minis included, stop on 14 January, and OpenAI suggests gpt-6-luna for them. Treat all three as one project, or you'll run the same regression tests three times.
  10. 06 Jan 2027ahead Then: speech and transcription models If you run call transcription or voice prompts, you've got your own set of dates to plan around. The tts-1 models and gpt-4o-mini-tts stop on 6 January 2027, and gpt-realtime-2.1-mini is the replacement. Older realtime and audio models go on 20 January, along with one older mini transcribe snapshot. whisper-1 and the other gpt-4o transcribe models last until 26 February, so test replacements early.
the story · openai api estate

From the first call to a setup your own team can run.

Here's what usually prompts a call about your OpenAI API estate, what we do about it and in which order, and where you end up.

  1. chapter 01 · where it hurts

    Why teams reach out

    • Your code still calls a model on OpenAI's deprecations page. On the shutdown date those calls start failing, and you find out from the errors.
    • An internal tool still runs on the Assistants API and nobody has moved it to Responses yet.
    • One API key is shared by several teams and nobody has set a spend limit.
  2. chapter 02 · what we change

    How we solve it

    • Model and API migrations
    • Agents and tool use
    • Retrieval on your data
    • Evaluation and monitoring
    • Security, keys and spend
  3. chapter 03 · how it runs

    Our approach

    • Usage and model inventory
    • Evaluation set first
    • Migrate and add tools
    • Projects, keys and limits
    • Monitor and hand over
  4. chapter 04 · where you end up

    What changes

    • Both the batch job and the app now run on current models, and the scores that chose them are on record.
    • Each team now sees its own usage against its own limit.
    • A list of the model IDs your code actually calls, each with its shutdown date, so nobody learns about one from a failed call.
    • We write a test set that scores every model or prompt change, so nobody argues from gut feel.
what we do

Our OpenAI API work

5 kinds of OpenAI API work, each run by engineers who have done it on live tenants.

  1. Code moved off retired models and the Assistants API onto the Responses and Conversations APIs, with side-by-side evaluation before cut-over.

  2. Agents built with the Agents API or Agents SDK, calling your internal APIs through tools with scoped credentials and logged actions.

  3. File search or your own vector store over approved documents, with access checks so users only get answers from content they may already see.

  4. Test sets built from real questions, automated scoring on every prompt or model change, and production logging for cost, latency and failure review.

  5. Projects, service accounts and key rotation set up per application, with spend limits and data retention settings reviewed with your security team.

capability 01 / 05in production

Model and API migrations

Code moved off retired models and the Assistants API onto the Responses and Conversations APIs, with side-by-side evaluation before cut-over.

capability 02 / 05in production

Agents and tool use

Agents built with the Agents API or Agents SDK, calling your internal APIs through tools with scoped credentials and logged actions.

capability 03 / 05in production

Retrieval on your data

File search or your own vector store over approved documents, with access checks so users only get answers from content they may already see.

capability 04 / 05in production

Evaluation and monitoring

Test sets built from real questions, automated scoring on every prompt or model change, and production logging for cost, latency and failure review.

capability 05 / 05in production

Security, keys and spend

Projects, service accounts and key rotation set up per application, with spend limits and data retention settings reviewed with your security team.

typical situations

OpenAI API situations we walk into

We pieced these together from OpenAI API situations that come up a lot. They're patterns. You won't find a specific client in them.

case file 01

A nightly batch job still pinned to a model with a shutdown date

composite · not a client story
  1. Beforethe situation

    A nightly claims-summary job is pinned to gpt-5-2025-08-07, and a customer-facing app depends on saved prompt objects through v1/prompts. Both have published shutdown dates. The only testing anyone does is one person reading ten outputs.

  2. What we dothe work

    We pull a few hundred past inputs into a graded test set and run the GPT-6 candidates against it. The winner is picked on score, cost and latency. Prompt objects become versioned files in your own repo, and model IDs move into config, so the next swap is just a change request.

  3. Afterwhere you end up

    Both the batch job and the app now run on current models, and the scores that chose them are on record. Prompts live in your repo next to the code. When OpenAI posts the next shutdown date, someone reruns the test set and reads the numbers.

case file 02

One API key shared by every team in the company

composite · not a client story
  1. Beforethe situation

    Every internal app reads the same OpenAI API key from one vault path. It has never been rotated. Finance can't split the bill by team, and security has never looked at the retention settings.

  2. What we dothe work

    We create a project for each application, with its own service account and key, and set a spend limit on each. Keys rotate through your secrets manager. Security reviews the data retention and logging settings with us, and we record what was agreed.

  3. Afterwhere you end up

    Each team now sees its own usage against its own limit. A leaked key hits one app, and only that key gets revoked. Security keeps the agreed retention settings in writing.

approach

How a OpenAI API engagement runs

We don't start a step until the last one has produced something you can check.

  1. step 01

    Usage and model inventory

    First we find out what you actually call. We search code, config and usage logs for model IDs and keys, then check each one against OpenAI's deprecation page. Whatever breaks first gets fixed first.

  2. step 02

    Evaluation set first

    Before anybody touches a prompt or a model, we build a test set from real requests and write scoring rules. Changes then win or lose on evidence.

  3. step 03

    Migrate and add tools

    We move the code to the Responses API or the Agents API. When a model wants a tool, your own service makes the call to the internal API, with credentials scoped to that one job.

  4. step 04

    Projects, keys and limits

    Every app gets its own project and service account, and a spend limit someone actually set. Your security team sits down with us to go through the retention settings.

  5. step 05

    Monitor and hand over

    Cost, latency and failure logs go live on the same day as the app. Your team also gets a monthly habit of checking OpenAI's deprecation list, so the next date isn't a surprise.

architecture

Where your app's requests to OpenAI actually go

Users sign in with Entra ID. Requests go out to the Responses or Agents API through your gateway, which holds the keys and the limits. If the model asks for a tool, your service makes the internal API call with scoped credentials and logs what came back.

Where your app's requests to OpenAI actually go Users sign in with Entra ID. Requests go out to the Responses or Agents API through your gateway, which holds the keys and the limits. If the model asks for a tool, your service makes the internal API call with scoped credentials and logs what came back. 01 · APPLICATION 02 · YOUR SERVICE LAYER 03 · OPENAI 04 · YOUR DATA AND SYSTEMS OIDC sign-in request API call agent run file search function calls scoped queries eval runs Ex Entra ID user sign-in ·groups Your application web app · Teams · portal Model gateway keys · spend limits · logs Evaluation suite test sets · graders AI Responses API GPT-6 · functioncalling Agents API multi-step agent runs Vector store approved documents Internal APIs orders · tickets · HR Snowflake read-only analyticsrole © Cohash · cohash.com
01 · APPLICATION02 · YOUR SERVICE LAYER03 · OPENAI04 · YOUR DATA AND SYSTEMS Entra ID: user sign-in · groups Entra ID user sign-in ·groups Your application: web app · Teams · portal Yourapplication web app · Teams ·portal Model gateway: keys · spend limits · logs Model gateway keys · spendlimits · logs Evaluation suite: test sets · graders Evaluationsuite test sets ·graders Responses API: GPT-6 · function calling Responses API GPT-6 · functioncalling Agents API: multi-step agent runs Agents API multi-step agentruns Vector store: approved documents Vector store approveddocuments Internal APIs: orders · tickets · HR InternalAPIs orders ·tickets · HR Snowflake: read-only analytics role Snowflake read-onlyanalytics role request API call agent run file search function calls scoped queries eval runs © Cohash · cohash.com
use cases

Typical OpenAI API projects

The work teams usually bring us, and the platforms OpenAI API has to talk to while we do it.

  1. OPE-01 Your app still calls a model that's on OpenAI's deprecation list, and nobody has picked a replacement common request
  2. OPE-02 Something you built on the Assistants API still needs moving to Responses, and the old API is already gone common request
  3. OPE-03 Anyone can get your chatbot to quote a file they aren't allowed to open common request
  4. OPE-04 Prompts get changed in production and nobody checks whether the answers got worse common request
  5. OPE-05 Every team uses the same API key, and nobody has set a spend limit on it common request
you keep

What a OpenAI API engagement leaves behind

These are working documents, written against your configuration, so your team can run them without us.

  • inventory01

    A list of the model IDs your code actually calls, each with its shutdown date, so nobody learns about one from a failed call.

    yours to keep
  • tests02

    We write a test set that scores every model or prompt change, so nobody argues from gut feel.

    yours to keep
  • document03

    Saved prompt objects moved into your repo before v1/prompts shuts down, so nothing still calls it on the day.

    yours to keep
  • document04

    Eval suite moved off OpenAI Evals into your repository and CI before the 30 November shutdown

    yours to keep
  • document05

    A project and service account per app, with keys that rotate and a spend limit someone actually set.

    yours to keep
  • document06

    Access checks for each document source, so retrieval doesn't leak what a user couldn't open.

    yours to keep
talent and delivery · openai api

Certified engineers, wherever you need them.

Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.

Onsite

Engineers at your sites in the US

Nearshore

Overlapping hours with US teams

Offshore

Overnight progress on your backlog

All time zones

Coverage handed over across time zones

24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
roles we staff
  • AI engineer (OpenAI API, Agents SDK)
  • LLM evaluation engineer
  • Retrieval and RAG engineer
  • AI application back-end developer
  • AI security engineer
  • Forward deployed AI engineer
01What's shutting down next on the OpenAI API, and when do we have to move?

Existing evals went read-only on 31 October 2026, and on 30 November OpenAI turns off Evals, Agent Builder and the v1/prompts API together. GPT Image 1 Mini and 1.5 go on 1 December. The first GPT-5 snapshots and o3 go on 11 December, then GPT-4o and GPT-4.1 on 14 January 2027. Search your code and config for those model IDs now. After each shutdown date calls fail, unless you've arranged dedicated capacity with OpenAI.

02How often do we need to change models?

Often. Look at OpenAI's deprecations page for 2026 and most months have a shutdown on them. We pin model versions, keep an evaluation set ready and review the list on a schedule, so migrations are planned rather than forced.

03OpenAI Evals is shutting down. What do we use instead?

OpenAI's own pointer is Promptfoo, and it has a migration guide for it. We'd rather the test set and graders live in your repo anyway, so they run in CI on every prompt or model change. Pull your eval data out before the 30 November shutdown, then rebuild the suite on your side.

04Can we still fine-tune OpenAI models?

Only if you're an active fine-tuning customer already, and only until 6 January 2027. From that date nobody can start a new job. Models you've tuned keep serving until their base model is retired. So a GPT-4o or GPT-4.1 fine-tune stops working on 14 January 2027, and you'll need a plan for whatever it was doing.

05Should we call the OpenAI API directly, or go through Azure?

That comes down to your contracts, data residency rules and the models you actually need. If you've already standardized on Azure and Entra ID, Azure OpenAI usually fits. Model availability and release timing don't always match between the two, so we check both for your use case before anyone signs.

06Why is our OpenAI API bill so high, and how do we cut it?

Mostly it's the model you pick, how many tokens each request burns and how often you call it. Prompt caching helps, and so do smaller models for the simple steps and shorter context. We'd rather measure your real traffic first and recommend changes after.

07Agent Builder shuts down on 30 November. Can you move our workflows off it?

Yes. It shuts down on 30 November 2026, and OpenAI points people to the Agents SDK or ChatGPT Workspace Agents. ChatKit isn't affected. We list every workflow someone built in Agent Builder, rebuild each one in your own code, and run old and new on the same inputs before you switch.

services

Related services

Projects on OpenAI API usually end up touching one of these, so they're worth a look.

fact-checked Checked against vendor and official documentation last checked 2026-11-08 content fingerprint ab9e7ef0
  1. 01Book a 30-minute working sessionsenior engineer
  2. 02Talk to an engineer about your setupreply within 24 hours
  3. 03See how similar projects wentcase studies
Reviewed by the Cohash team OpenAI API is a trademark of its owner, used here to identify the platform. how we handle facts and data →
next step

Tell us what you're running. We'll tell you what we'd do first.

A 30-minute working session with a senior engineer. No slides.

useful to bring
  • The platform and the version you're on
  • Where you need to get to, and by when
  • What's custom: rules, plugins, integrations
  • Any audit finding or deadline driving it