August 3, 2026

Optic Alternative: What to Use Now That Optic Is Archived

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:

1. 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.
2. 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.