Optic Is No Longer Maintained — Here's How to Keep Catching Breaking API Changes

If you've been using Optic to catch breaking changes in your OpenAPI specs, you've probably noticed: the repository was archived on January 12, 2026. The last issue, titled "No Longer Maintained," was opened four days earlier. The final release (v10.3.0) shipped, and that was it.

Optic was a good tool. It was backed by Y Combinator, had 1,500+ GitHub stars, and companies like Snyk used it in production. But it required a CLI setup, a config file, CI pipeline integration, and custom rulesets written in TypeScript. For many teams, that setup cost meant the tool never made it past the "we should try this" stage.

So what now?

The problem hasn't gone away

Breaking API changes still ship to production every day. A field gets renamed, an endpoint gets removed, a required parameter becomes optional — and downstream services break silently. If you've ever debugged a 500 error that turned out to be a renamed JSON field in an upstream service, you know the pain.

The need for automated breaking change detection in pull requests is arguably stronger than ever, with more teams adopting API-first development and microservice architectures.

What Optic did well

Optic brought several important ideas to the API governance space: diffing OpenAPI specs to find breaking changes, integrating results into code review, and applying custom linting rules to API design. It also supported generating OpenAPI specs from traffic, which was a unique feature for teams without existing specs.

What made it hard to adopt

For teams that just wanted "tell me if my PR breaks the API," Optic required significant setup:

• Install the CLI globally (npm install -g @useoptic/optic)
• Create an optic.yml configuration file
• Set up a GitHub Action or CI pipeline step
• Write custom rulesets in TypeScript for anything beyond defaults
• Manage API tokens and cloud connections

This was powerful for platform teams with dedicated API governance roles. But for most engineering teams — the ones with 5–20 services, a few OpenAPI specs, and no dedicated API platform engineer — it was too much friction.

What I built instead

I ran into this exact problem at work. We had 4 microservices with OpenAPI specs, and breaking changes kept slipping through PRs. I tried Optic, spent an afternoon configuring it, and thought: why does this need a CI pipeline and a config file?

So I built CodeRifts — a GitHub App that does one thing well: it posts a full API governance report as a PR comment every time someone modifies an OpenAPI spec.

The setup is literally:

1. Install the GitHub App (one click)
2. Open a pull request

That's it. No config file. No CI changes. No CLI. It auto-discovers your OpenAPI specs (YAML or JSON, versions 2.0, 3.0, and 3.1) and analyzes them on every PR.

What the report includes

Every PR that touches a spec gets a comment with:

• Risk Score (0–100) across 4 dimensions: revenue impact, blast radius, app compatibility, and security
• Breaking change detection for 10 types: removed endpoints, deleted fields, type changes, enum value removal, and more
• Policy violations — configurable rules like "never delete a /payments/* endpoint" or "maximum 3 breaking changes per PR"
• Security analysis — auth removal detection, OAuth scope changes, sensitive field exposure (OWASP-aligned)
• Semver suggestion — concrete MAJOR/MINOR/PATCH recommendation based on what actually changed
• Auto-generated changelog — grouped by Breaking, Added, Changed, Deprecated

See a real example: Demo PR with full governance report →

Comparison: Optic vs CodeRifts

Other alternatives

If you liked Optic's CLI-first approach and want something you fully control, there are other options worth considering:

• oasdiff — an open source OpenAPI diff tool, solid for CI pipelines, but no GitHub integration or governance features beyond diffing
• Swagger diff — basic diffing, limited to Swagger 2.0
• Fork Optic — it's MIT licensed, though maintaining a fork solo is a significant commitment

Each has tradeoffs. If all you need is a raw diff, oasdiff is great. If you want governance — risk scoring, policies, security checks, team routing — without the setup overhead, that's the gap CodeRifts fills.