DEV Community: DriftSignal

The OpenAI Assistants API Dies Today, and the Loud Shutdown Isn't the One That Gets You

DriftSignal — Wed, 26 Aug 2026 18:21:05 +0000

As of today, August 26, 2026, the OpenAI Assistants API is gone. Every call to /v1/assistants, /v1/threads, and /v1/threads/runs now returns a hard error. There is no grace period, no degraded mode, and no extension. If your chatbot, workflow, or internal tool still runs on it, it stopped working this morning.

This is the loud kind of failure, and loud is the easy kind. The endpoint errors, your logs light up, and you know exactly what broke and why. OpenAI announced it a year ago, on August 26, 2025. The date sat on the calendar the whole time. Every team that got caught today got caught by a deadline they could see coming.

The failures worth worrying about are the ones you cannot see coming. This migration is full of them.

The loud failure everyone planned for

The Assistants shutdown is about as visible as an API change gets. It comes with hard errors on named endpoints, on a date announced twelve months in advance. OpenAI published a migration guide pointing to the Responses API plus the Conversations API. The coverage was everywhere.

The blast radius reached further than most teams expected. Zapier retired every ChatGPT step built on the Assistants API. Azure OpenAI's Assistants API retires on the same date, even though earlier guidance suggested Azure was unaffected.

If you migrated, you already dealt with the loud part. Good. But "the old endpoint returns an error" is the failure mode your monitoring already catches. The migration you just shipped introduced a second kind of failure that nothing is watching for.

The silent failures hiding inside the migration

Moving from Assistants to Responses is not a rename. Assistants became Prompts. Threads became Conversations. Runs became Responses. Run Steps became Items. Those objects do not carry the same responsibilities they used to. When you swap one architecture for another under a hard deadline, the failures that survive your testing are the ones that stay quiet.

Here is what quiet looks like in this migration.

A field moves or changes shape. The response structure is different now. If your code reads a value that lived in one place under Runs and now lives somewhere else under Responses, it does not crash. It reads a null or a default and keeps going.

State does not come across. OpenAI has said plainly that there is no automated tool to migrate Threads to Conversations. Teams are rebuilding conversation history by hand. A gap there throws no error. The agent simply answers with less context than it had yesterday.

A tool call quietly stops firing. Tool orchestration works differently now. A tool that used to run inside a Run can, in a rushed Responses call, fail to fire at all. The model then produces a confident answer without it, and the call still returns a 200.

Cost and behavior drift. The Responses API prices and behaves differently. Nothing errors when your token usage doubles or a default shifts. You find out on the invoice or in a user complaint.

Every one of these returns success. The migration looks like it worked. The damage shows up downstream, in wrong data, missing context, or a workflow that quietly does less than it did before, and it usually shows up when a user notices before you do.

Why this is worse for AI agents

For a plain data integration, a silent drift produces a wrong number in a report. For an AI agent, it produces something harder to catch. The agent keeps answering, confidently, on degraded input. A missing tool result or truncated context does not make the model stop. It makes the model guess, fluently, and hand you the guess as if it were fact. Silent degradation in an agent is not downtime. It is confident wrongness, which is exactly the kind of failure that survives a demo and breaks in front of a customer.

The pattern underneath today's headline

Strip away the specifics and this is the same shape as every API change. The announced shutdown, the hard error on a date you can plan for, is the part everyone prepares for, because it is visible. The response model shifting underneath the migration is the part that fails without erroring. Your tests cannot catch it, because your tests validate your code against the contract you think the new API has, and that assumption is exactly what is shaky when you are migrating fast against an unfamiliar architecture.

This is API contract drift. The live API stops matching the contract your code was written against while still returning valid responses. A hard shutdown is the loud, honest cousin of drift. The migration you ship to escape it is where the quiet version lives.

Contract testing helps at build time, but it checks your code against your assumptions about the new API, and those assumptions are the weak link during a rushed migration. The gap between "the call succeeded" and "the call did what I meant" is the job of runtime monitoring.

What to actually do after you migrate

Getting off the dead endpoint is step one. Confirming that the replacement does what the old one did is the step most teams skip.

Validate the new responses against a schema at the boundary, so a moved field or a missing value fails loudly in your own system instead of slipping through as a null. Check the values, not just the status code, because a 200 from the Responses API tells you the call succeeded and nothing about whether the tool ran or the output is shaped the way your downstream code expects. Where you still can, run the same input through the old path and the new one and compare the results, because the differences you did not expect are the ones that hurt. And keep checking the live endpoint on a schedule after cutover, because provider behavior keeps changing after your migration is "done."

The lesson outlives the deadline

August 26 is one shutdown of one API. If you never touched the Assistants API, today is not your problem. But the shape of it is everyone's problem. The loud failure arrives on a scheduled date you can plan around. The migration you ship to survive it carries silent ones that arrive whenever they feel like it. The question is never whether you beat the deadline. It is whether you notice the quiet breakage the migration introduced before your users do.

Frequently asked questions

When does the OpenAI Assistants API shut down?

August 26, 2026. After this date, calls to /v1/assistants, /v1/threads, and /v1/threads/runs return hard errors with no grace period, degraded mode, or extension. OpenAI announced the deprecation exactly one year earlier, on August 26, 2025. The Azure OpenAI Assistants API retires on the same date.

What replaces the Assistants API?

The Responses API, paired with the Conversations API for persisting chat history. It is a full architectural change rather than an endpoint rename. Assistants become Prompts, Threads become Conversations, Runs become Responses, and Run Steps become Items. These objects do not have identical responsibilities, so migration means rewriting integration logic rather than swapping a URL.

Is there an automated migration tool?

No. OpenAI has said it will not provide an automated tool to migrate Threads to Conversations. Conversation history does not carry over on its own, so teams export and rebuild it by hand. Vector stores and files persist and move to the Responses API file search tool, but assistant definitions and threads do not.

Why is the silent failure risk higher than the shutdown itself?

The shutdown is a loud, visible failure, with hard errors on a known date that your monitoring catches right away. The migration to the Responses API introduces silent failures instead: moved or reshaped response fields, incomplete state migration, tool calls that quietly stop firing, and cost or behavior drift. All of these return successful responses, so they pass testing and surface downstream. For AI agents the risk is higher still, because the agent keeps answering confidently on degraded input rather than failing outright.

Optic Alternative: What to Use Now That Optic Is Archived

DriftSignal — Mon, 10 Aug 2026 17:28:12 +0000

If you're here, you probably already know: Optic is gone. The opticdev/optic repository was archived on January 12, 2026, following Atlassian's acquisition of the project back in April 2024. The expected integration into Atlassian Compass never shipped, the useoptic.com domain no longer resolves, and no community fork has stepped up to carry it forward. If you depended on Optic to catch API changes, you need a plan.

The good news is that the plan is clear once you separate what Optic actually did into its distinct jobs — because the right replacement depends entirely on which of those jobs you relied on.

What Optic actually did

Optic was a well-liked, YC-backed, MIT-licensed tool with a clean CLI and deep CI integration. It really did two separate things:

Breaking-change detection via spec diffing. You ran optic diff in CI, and it compared your new OpenAPI spec against the previous one, flagging incompatible changes — a removed field, a changed type, a newly-required parameter — before they shipped. Its GitHub Action posted the results as PR comments.
Keeping your OpenAPI spec accurate from traffic. Optic ran your API tests through a proxy, watched the real behavior, and helped you patch the spec when an endpoint had changed or a new one appeared.

Both jobs share a defining trait, and it's the key to choosing a replacement: Optic worked at build time, on your own API's spec. It compared documents and observed test traffic in CI. It was never a production monitor, and it wasn't built to watch APIs you don't control.

The honest drop-in for Optic's spec diffing

If what you used Optic for was optic diff in CI — catching breaking changes in your own spec before merge — the closest direct replacement is oasdiff. It's an open-source CLI and GitHub Action, Apache 2.0 licensed and actively maintained, and it does the spec-versus-spec breaking-change detection that was Optic's core. It'll slot into your pipeline and post PR feedback much the way Optic's action did.

The one Optic capability without a clean drop-in is the traffic-to-OpenAPI generation — spinning up a spec by observing your test traffic through a proxy. There's no single tool that reproduces that workflow exactly, so if that was central to how you worked, expect to adopt a different approach rather than a like-for-like swap.

So for the pure CI job, you're covered, and we'd genuinely point you to oasdiff. But that's not the whole story of why teams are rethinking this now.

The gap Optic never covered

Here's what spec diffing in CI — Optic's, oasdiff's, anyone's — structurally cannot catch: whether your API, or the third-party APIs you depend on, actually behave like their spec in production.

Spec diffing compares two documents. It answers "does my new spec break my old spec?" It says nothing about whether the running service matches the spec at all. A spec can pass every diff in CI and still describe a service that, in production, returns a field as a string when the spec says integer, emits a status code the spec never declared, or drops a field that's marked required. That mismatch between the contract and the live service is API contract drift, and it's a runtime problem that a build-time tool was never designed to see.

It bites hardest with the APIs you consume. When a provider changes their API, no diff in your CI fires — you didn't change anything. The first signal is usually a broken integration. I've written about a version of this that cost me a day of debugging, where a published contract simply didn't match the running service.

Where DriftSignal fits

DriftSignal isn't a replacement for optic diff, and we won't pretend otherwise — for CI spec diffing, oasdiff is the tool. DriftSignal covers the dimension Optic left open: runtime contract drift.

It polls your live GET endpoints on a schedule, validates each response against your OpenAPI spec, and alerts you the moment a real response diverges from the contract — classifying each divergence (missing required field, type mismatch, unexpected null, undocumented status code, and softer drift like undocumented fields, enum values, or format changes) by whether it's breaking or merely drifting. Where Optic asked "does my new spec break my old one?" before merge, DriftSignal asks "does the live service still match the spec?" continuously, in production, including for third-party APIs you don't control.

Many teams will want both: a CI diff tool like oasdiff to catch breaking changes they introduce, and runtime monitoring to catch drift they didn't. They solve different halves of the same problem.

Choosing your replacement

A quick way to decide, based on what you valued about Optic:

You used optic diff in CI to catch breaking changes in your own spec → oasdiff is your drop-in.
You used Optic to generate/maintain a spec from test traffic → no direct drop-in; plan a different spec-maintenance workflow.
You cared about catching API changes before they broke something in production → that's runtime drift detection, and it's what DriftSignal does — for your own live APIs and the third-party ones you depend on.

Optic was a good tool, and its absence is a real loss. But the migration is also a chance to close a gap it never covered: knowing, continuously, whether the services you depend on still match what their contracts promise.

Frequently asked questions

What happened to Optic?

Optic's GitHub repository was archived on January 12, 2026, following Atlassian's acquisition of the project in April 2024. The anticipated integration into Atlassian Compass never shipped, the useoptic.com domain no longer resolves, and no community fork has emerged as a successor. The code is now read-only and unmaintained.

What is the best Optic alternative?

It depends on what you used Optic for. For breaking-change detection via spec diffing in CI, oasdiff is the closest open-source drop-in. For generating an OpenAPI spec from test traffic, there is no clean like-for-like replacement. And for catching API changes in production — runtime contract drift, which Optic never covered — you need live response monitoring rather than a build-time diff tool.

Is there a drop-in replacement for Optic?

For its core CI spec-diffing, yes: oasdiff is an actively maintained, open-source CLI and GitHub Action that catches breaking changes between spec versions. For Optic's traffic-to-OpenAPI generation there is no direct equivalent, so that workflow needs to be replaced rather than swapped.

Did Optic detect API drift in production?

No. Optic worked at build time, comparing OpenAPI spec versions in CI and generating specs from test traffic. It did not continuously validate that a live service matched its spec, and it wasn't designed to watch third-party APIs you consume. Catching drift in production requires runtime monitoring that validates real responses against the spec on a schedule.

What Is API Contract Drift? Types, Causes, and How to Detect It

DriftSignal — Thu, 06 Aug 2026 13:29:44 +0000

API contract drift is when a live API's responses stop matching the contract that describes them — a field changes type, a documented field disappears, an undocumented status code appears — while the endpoint keeps returning a perfectly valid response. It isn't an outage. Nothing errors. The endpoint answers with a clean 200. The response is just no longer the shape your code was written to expect.

Drift is one of the most common and least-monitored reliability problems in any system that depends on APIs — your own or someone else's. This guide covers what it is, the specific forms it takes, why your existing tooling doesn't catch it, and how to detect it in production.

Contract drift vs. an outage: why drift is invisible

An outage is loud. Error rates spike, requests time out, alerts fire, and someone gets paged. Everyone knows what to do.

Drift is quiet. The endpoint returns a valid 200 OK. Your uptime monitor is green. Your status page says everything is fine. And yet the data flowing into your system is subtly wrong — a field is missing, a number is the wrong type, a value is in a format your parser doesn't understand. To any tool that only checks whether the endpoint responded, a drifted response and a correct response look identical.

That is the whole problem in one sentence: "the API is up" and "the integration is working" are two different claims, and most monitoring only checks the first one. By the time drift becomes visible — a broken report, a failed reconciliation, a customer complaint — it has usually been live for days or weeks, quietly feeding bad data downstream.

The types of API contract drift

Not all drift is equal. Some changes break consuming code immediately; others erode the contract quietly and often precede an outright break. It helps to split them by severity.

Breaking changes — these will break code that trusts the contract:

Missing required field. A field the spec guarantees stops appearing in responses. Code that reads it gets a null, a KeyError, or a crash.
Type mismatch. A field's type changes — a numeric ID starts arriving as a string, a boolean becomes 0/1. Deserialization fails or, worse, silently coerces to the wrong value.
Unexpected null. A field the spec marks non-nullable returns null. The classic "this was never supposed to be empty" bug.
Undocumented status code. The endpoint returns a status the spec never declared. Retry logic, error handling, and circuit breakers built around the documented set behave unpredictably.

Drift — softer changes that erode the contract and warn of trouble:

Undocumented field. A new field appears that isn't in the spec. Harmless today, but it means the spec and the service have diverged — and the next divergence may not be harmless.
Undocumented enum value. A field returns an enum value the spec doesn't list. A switch or match written against the documented values falls through.
Format mismatch. A value's format changes while its type stays the same — a date switches from ISO-8601 to epoch, a currency from dollars to cents. The type checker sees a valid string or number; your logic sees garbage.

Every one of these returns a 200. That severity split — breaking versus drift — is the difference between "page someone now" and "flag this before it becomes breaking," and it's why detecting drift is about more than a pass/fail check.

Why your existing tooling misses contract drift

If you already have tests and monitoring, it's fair to ask why they don't catch this. Here's the honest accounting:

Uptime monitoring answers whether an endpoint responded, and that question stops being useful the moment a response can be wrong without being an error. A drifted 200 and a correct 200 are indistinguishable to it.

Contract tests (tools like Pact, Dredd, or Schemathesis) are valuable, but against a third-party API they cover only the paths you wrote assertions for, on the schedule your tests run, with your test account's data. Real production traffic exercises far more surface than any test suite. Keep them for your scariest paths, but treat them as a floor, not coverage.

Integration tests validate your assumptions against the contract — and the contract is exactly the thing that's wrong when it drifts. A green suite tells you your code matches the spec, not that the spec matches the live service.

Spec diffing (comparing today's OpenAPI document to yesterday's) only works if the provider publishes an updated spec. The changes that cause incidents are usually the ones nobody upstream classified as worth announcing — so the spec never changes, even though the behavior does.

The common thread: nearly every layer validates against the contract, and no layer validates the contract against reality. I wrote about a concrete version of this — a published contract that was simply wrong, and broke a client at runtime — if you want the war story behind the principle.

What causes API contract drift

Drift isn't malice; it's the natural result of independently evolving systems:

A provider ships a change they consider non-breaking (adding a field, tightening a value) without announcing it.
A vendor migrates infrastructure and a serialization detail changes — timestamps normalize to UTC, a default page size shrinks.
Two internal teams own a producer and a consumer of the same API, and one ships without coordinating with the other.
A spec is written once at integration time and never kept in sync with the implementation, so it slowly becomes fiction.

You can't prevent a third party from changing their API. What you can control is how fast you find out.

Where API contract drift causes damage

The cost compounds the longer drift goes unnoticed:

Billing and finance. A currency or unit change misreports revenue; nobody notices until reconciliation, by which point it's in quarterly numbers.
CRM and lead pipelines. A renamed webhook field means leads arrive incomplete, and sales doesn't notice for weeks because the record still shows up.
Data and reporting. A field used in a metric quietly changes type; the dashboard doesn't error, it just shows a wrong number that people make decisions on.
Internal microservices. A backend change ships ahead of the frontend or a downstream service, and the same silent mismatch happens inside your own walls.

A finance error caught the same day is an annoyance. The same error caught three months later is a much bigger problem.

How to detect API contract drift

You detect drift by validating real responses against the spec continuously, instead of only at build time. In practice that means: establish what each endpoint should return according to its OpenAPI spec, watch the live endpoint on a schedule, and alert the moment a real response diverges — a changed type, a missing field, an undocumented status code. The goal is to turn a silent divergence into a loud, actionable signal before it reaches your users.

Alongside monitoring, two defensive practices limit the blast radius: validate every external response against an explicit schema at the boundary so bad data fails loudly instead of propagating, and pin to versioned endpoints where a provider offers them so you control when you adopt changes.

How DriftSignal detects contract drift

This is the gap DriftSignal exists to close, for the REST and OpenAPI side of it. It polls your live GET endpoints on a schedule, validates each response against your OpenAPI spec, and classifies any divergence into the exact categories above — missing required field, type mismatch, unexpected null, undocumented status code, undocumented field, undocumented enum value, format mismatch — with a breaking-versus-drift severity so you know what to fix now and what to watch. It monitors what the service returns against what the contract claims, on a schedule, so you find out the day a response stops matching, not the day a customer does.

This post was originally published on the DriftSignal blog. DriftSignal continuously checks your live APIs against their OpenAPI specs and alerts you the moment they drift — see how it works.

When the Contract Lies: Detecting API Drift in Production

DriftSignal — Mon, 03 Aug 2026 17:17:35 +0000

Years ago I was integrating against a carrier's SOAP web service, and I did the most routine thing in the world: I pointed wsimport at their WSDL and let it generate a Java client.

wsimport -keep -s src/generated https://partner.example.com/service?wsdl

Clean build. Every type resolved. The generated proxy looked exactly like what the contract described — because it was exactly what the contract described.

Then the first real call failed. Not a compile error, not a serialization warning. A flat rejection from the server at runtime. One of the generated methods was missing a parameter that the server actually required. The client I'd built faithfully matched the published contract, and the published contract was wrong.

The contract lied, not the tooling

This is the part that stuck with me. wsimport didn't malfunction. My code didn't have a bug in any normal sense. The WSDL — the third party's own machine-readable description of their service — was incomplete. It advertised a method signature the running service didn't accept. Every tool in the chain did its job perfectly, and I still shipped a broken integration, because every tool trusted the contract, and the contract lied.

Here's the uncomfortable general lesson: a machine-readable API contract is only as trustworthy as its agreement with the running service. And almost nothing in your toolchain checks that agreement. Your compiler validates your code against the contract. Your codegen validates the client against the contract. Your tests, if you're disciplined, validate your assumptions against the contract. Every layer validates against the contract — and no layer validates the contract against reality.

What is API contract drift?

API contract drift is when a live API's responses stop matching the contract that describes them — a field changes type, a documented field disappears, an undocumented status code appears — while the endpoint keeps returning a perfectly valid response. It isn't an outage. Nothing errors. The endpoint answers with a clean 200. It just no longer returns the shape your code was written to expect.

Common forms of drift:

A field changes type — a numeric ID starts arriving as a string
A field that was always present becomes optional, or vanishes under some conditions
An undocumented status code or enum value appears
A date or currency format changes — ISO to epoch, dollars to cents
Pagination or envelope structure shifts underneath you

None of these trip a status code. All of them can silently corrupt the data flowing into your systems — into billing, reporting, or anything downstream — long before anyone notices.

How API drift shows up in REST and OpenAPI

That original incident was SOAP, and mine was a request-side bug — I was failing to send something the server wanted. It's not the exact failure I'd build a product around. But the shape of it is everywhere, and it didn't stay in the SOAP era.

Swap WSDL for OpenAPI and the story repeats itself constantly. A provider's spec says a field is a string; the live endpoint started returning null last Tuesday. The spec documents six status codes; production quietly added a seventh. An endpoint the spec still lists was deprecated and now returns a 404. Your generated client, your typed models, your contract tests — all green, all validated against a spec that no longer describes what the service actually does.

How to detect API drift in production

The only reliable way to catch this is to continuously detect API drift in production: check the live endpoint against its spec, on a schedule, and get told the moment they diverge. Not at your next release. Not when a customer opens a ticket. The moment it happens.

Two defensive practices help limit the damage in the meantime: validate every external response against an explicit schema at the boundary, so bad data fails loudly instead of propagating silently, and pin to versioned endpoints where a provider offers them, so you control when you adopt changes.

The day you find out

The lesson from that carrier integration never changed. Contracts drift from reality, they do it quietly, and your build is the last place that will ever tell you.

If you depend on third-party APIs — or you publish your own — the question isn't whether the spec is accurate today. It's whether you'll find out the day it stops being accurate, or the day your customer does.

This post was originally published on the DriftSignal blog. DriftSignal continuously checks your live APIs against their OpenAPI specs and alerts you the moment they drift — see how it works.