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

Migrating from Optic to CodeRifts

If you had Optic wired into your pipeline, here's the practical path to a working replacement. Most teams finish in under five minutes because there is nothing to configure for the default behavior.

1. Leave your optic.yml in place for now. You don't have to delete anything to try CodeRifts. The two tools don't conflict — Optic runs in CI, CodeRifts runs as a GitHub App on the PR. Run them side by side until you trust the replacement.

2. Install the GitHub App. One click at github.com/apps/coderifts. Grant it access to the repositories that contain your OpenAPI specs. No token management, no cloud account to provision.

3. Open a pull request that touches a spec. CodeRifts auto-discovers your OpenAPI files (YAML or JSON, 2.0 / 3.0 / 3.1) and posts a full governance report as a PR comment — risk score, breaking changes, security findings, semver suggestion, and changelog. This is the equivalent of Optic's diff-plus-rules step, with no CI job to maintain.

4. Port your Optic rulesets (optional). Anything you wrote as a custom TypeScript ruleset in Optic maps to a single .coderifts.yml policy file. Where Optic needed code, CodeRifts uses config-as-code:

# .coderifts.yml — optional; defaults work with no file at all
policies:
  - name: protect-payments
    rule: no_endpoint_removal
    match: "/payments/*"
    severity: block
  - name: cap-breaking-changes
    rule: max_breaking_changes
    value: 3
    severity: warn

5. Remove the Optic CI step once you're satisfied. Delete the GitHub Action or pipeline stage and the optic.yml. The PR comment is now your governance gate.

One thing Optic did that CodeRifts does not yet do: generate an OpenAPI spec from live traffic. If you depend on traffic capture for spec generation, keep that part of your workflow for now — it's on the CodeRifts 2026 roadmap. For breaking-change detection and governance on specs you already maintain, the migration is a drop-in.

Other alternatives

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

• oasdiff - open source OpenAPI diff, solid CLI and GitHub Action; a hosted Pro tier (oasdiff.com) now adds PR comments and per-change approvals. Strong on diff classification; no risk scoring, cost estimation, or agent-facing API.
• 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.

What to check before you pick a replacement

Three questions worth asking any Optic replacement in 2026:

1. Does it tell you HOW RISKY a change is, or only THAT something changed? A severity label is not a risk model. CodeRifts scores every change 0-100 and estimates the cost of shipping it.
2. Can you prove what was decided? If an approved change breaks production, review history says who clicked. A signed verdict receipt proves what the engine saw and decided - externally verifiable, Ed25519.
3. Will AI agents consume it? Agents are becoming the biggest consumers of API contracts. CodeRifts exposes verdicts through an agent-native API and MCP server.

Using CodeRifts inside an AI agent — something Optic never did

Optic was built for human code review: a CLI, a CI job, a PR. That model assumes a person is in the loop. But more and more API changes are now proposed, reviewed, and even executed by AI agents — LangGraph and AutoGen workflows, autonomous coding agents, MCP-connected tools. None of them open an optic.yml or read a PR comment.

CodeRifts exposes the same governance verdict over a zero-auth public endpoint, so an agent can check whether an API change is safe before it acts on it. No API key, no signup:

curl -s -X POST https://app.coderifts.com/api/v1/demo \
  -H "Content-Type: application/json" \
  -d '{"old_spec": "<your previous OpenAPI>", "new_spec": "<your current OpenAPI>"}'

The response is a single structured verdict: decision (ALLOW / WARN / BLOCK), risk_score, safe_for_agent, the detected breaking-change patterns, and the reflex triggers that escalated the decision. One call, one machine-readable answer.

To make that a one-line guardrail in any framework, there's a zero-config decorator. It has no dependencies beyond the Python standard library, it's framework-agnostic (LangGraph, AutoGen, or a plain function), and it caches the verdict per spec pair so it hits the endpoint once, not on every invocation:

from coderifts_guard import coderifts_guard, CodeRiftsBlocked

@coderifts_guard(old_spec=previous_openapi, new_spec=current_openapi)
def run_agent_step(payload):
    # This body only runs if CodeRifts does not return BLOCK.
    # On BLOCK it raises CodeRiftsBlocked before any side effect.
    return call_downstream_api(payload)

If the change would break a downstream contract, the decorator raises CodeRiftsBlocked and the agent halts before the unsafe call ever leaves the process. There's also an explicit LangGraph guard node for teams that prefer to model the gate as a graph edge.

The full, runnable reference implementation — decorator plus LangGraph node — is public: github.com/coderifts/example-langgraph-guard

This is the part of API governance that an archived, CLI-first tool can't reach: stopping a bad change inside an automated agent loop, not just flagging it for a human after the fact.

Install the GitHub App, point it at the repos Optic watched, and your next PR gets a full governance report. Migration takes minutes, not days.

Frequently asked questions

Is Optic still maintained?
No. The Optic repository was archived on January 12, 2026. The final release was v10.3.0, and the last issue — titled "No Longer Maintained" — was opened four days before the archive. It still works if you've pinned it, but it will not receive updates, fixes, or new OpenAPI version support.

What is the best alternative to Optic for catching breaking API changes?
It depends on what you used Optic for. If you only need a raw diff in a CI pipeline, oasdiff is a solid open-source choice. If you want governance — risk scoring, policy enforcement, security analysis, and PR-native delivery — without the setup overhead, CodeRifts is the closest drop-in: it installs as a GitHub App in about 30 seconds and needs no config file or CI changes.

Can I migrate my Optic rules to CodeRifts?
Yes. Optic's custom TypeScript rulesets map to a single .coderifts.yml policy file (config-as-code). The default behavior needs no configuration at all — you only add policies if you want to enforce specific rules like never removing a /payments/* endpoint.

Does CodeRifts require a CI pipeline like Optic did?
No. Optic required a CLI install, an optic.yml, and a CI or GitHub Action step. CodeRifts runs as a GitHub App and posts its report directly as a PR comment, so there is no pipeline to set up or maintain.

Can an AI agent use CodeRifts to check API changes before acting?
Yes, and this is something Optic never supported. CodeRifts serves its governance verdict over a zero-auth public endpoint (POST /api/v1/demo), and a zero-dependency @coderifts_guard decorator turns that verdict into a one-line guardrail for LangGraph, AutoGen, or any Python agent. On a BLOCK decision the agent halts before the unsafe call runs.

Does CodeRifts generate OpenAPI specs from live traffic like Optic did?
Not yet. Traffic capture and spec generation was one of Optic's unique features and is on the CodeRifts 2026 roadmap. Today CodeRifts analyzes the OpenAPI specs you already maintain, on every pull request.

How long does CodeRifts take to set up compared to Optic?
Optic typically took 30 to 60 minutes — CLI install, config file, CI integration, and writing rulesets. CodeRifts takes about 30 seconds: install the GitHub App and open a pull request.

Is CodeRifts free?
All Pro and Team features are free during the public beta, with no credit card required. After beta there is a free tier plus paid plans for larger teams.