Two things happened this week that should make you audit your AI stack for lock-in

Two unrelated events, four days apart.

Stripe agreed to acquire OpenRouter for north of $7B. OpenRouter is the neutral routing layer a lot of us adopted specifically so we wouldn't be married to one model provider. That neutral layer now has an owner with its own roadmap.

Then Claude Code had a run of outages, and the top comment in one of the threads was: if Claude is down, I am down.

I felt that second one personally. And after sitting with it I concluded it wasn't Anthropic's fault in any interesting sense. It was a coupling choice I'd made months earlier and never revisited.

This is a post about auditing that choice.

Run the coupling audit

Go through your AI-touching setup and mark every place that assumes one vendor. Mine came out worse than expected:

• Prompts written against one CLI's conventions
• Wrapper scripts calling a specific binary with specific flags
• Config files in one tool's schema (CLAUDE.md, .cursorrules, an AGENTS.md, three of them slightly out of sync)
• Scheduling and secrets living inside a vendor's platform
• Output formats my downstream scripts parsed by hand

Not one of those is a bad decision on its own. Together they meant a provider outage was a full stop rather than a degradation, and a pricing change would have cost me a rewrite weekend.

The useful question isn't "which provider is best." It's what happens to my work when this provider is unavailable or gets bought.

The principle: keep the work outside the tool

The fix that generalises is separating what you want done from what executes it.

If the work lives in a portable format and execution is a config value, switching providers costs you a line. If the work is expressed in one vendor's idioms, switching costs you a rewrite. That's the whole distinction, and it's an architecture decision, not a tooling preference.

Concretely, in Aeon a unit of work is a markdown file:

---
name: digest
description: "Generate and send a digest on a configurable topic"
metadata:
  mode: write
  var: ""
  requires:
    - XAI_API_KEY?
---

Today is ${today}. Generate a digest on ${var}.
[instructions in plain English]

That file contains no vendor. It's intent, permissions, and inputs.

Execution is declared separately:

harness: claude    # claude | codex | grok | pi | vibe | kimi

One adapter runs the same skill file on any of six agent CLIs. When Claude was having a week, that line became harness: codex and my scheduled work kept running. Nothing else changed: same file, same schedule, same output path.

The gateway is separate again, so the model provider and the CLI are independently swappable.

Be honest about what portability buys

It buys a floor, not parity.

Output quality varies meaningfully by task and harness. Some of my skills are noticeably worse on the fallback, and I switch back when the primary recovers. Anyone telling you the harnesses are interchangeable hasn't run the same workload across all of them.

But there's a real difference between degraded and stopped, and that difference is the entire argument. My morning briefing being 15% worse for two days is a non-event. My morning briefing not existing for two days is a thing I have to explain.

And what you still depend on

Worth stating plainly, because the alternative is dishonest: Aeon's model removes the model-provider dependency by leaning hard on a different one. Your agent is a GitHub repo and Actions is the runtime, so if GitHub is down, you're down.

You haven't eliminated a single point of failure. You've swapped it for one that's better diversified on the axis that was actually hurting you, and arguably more reliable. That's a trade, and you should make it knowingly.

A checklist that works on any stack

None of this requires the framework. If you take one thing from this post, take the audit:

1. Can you name the file your work lives in? If your prompts only exist inside a tool's UI or history, they aren't portable. Get them into version control.
2. Is the provider a config value or a code path? If switching means editing logic rather than a variable, you're coupled.
3. Do you own the schedule? Scheduling inside a vendor's platform means their outage is your outage twice over.
4. Do you own the record? If the only account of what happened is a summary the tool generated, you can't debug across a switch.
5. Have you actually tested the fallback? An untested failover isn't a failover. Run a week on the backup, deliberately, before you need it.

I'd failed four of those five in a setup I'd have described as "pretty clean."

If you want to look at the framework

Aeon is MIT licensed and the skills are readable markdown, so the fastest way to judge it is to open skills/ and read one.

• Repo: github.com/aeonfun/aeon
• Site and docs: aeon.fun
• Security disclosures: aeon.fun/security, 74 open-source repos with merged fixes, every entry linking the actual PR
• Harness adapter: the piece this post is about lives in harness-adapter/

Two setup gotchas that cost me time, in case you try it: gh defaults to the upstream repo, so run gh repo set-default <you>/aeon, and forked repos have Actions disabled until you enable them once in the Actions tab.

The takeaway

The lesson of this week isn't that Anthropic should communicate better during incidents, though they should. And it isn't that Stripe buying OpenRouter is bad, it may well be good for the product.

It's that most of us are one vendor decision away from a stoppage we chose ourselves and never revisited. Both events were reminders arriving from different directions.

Mine had been sitting there for months. Worth an hour of your time to find yours.

---

What did your audit turn up? Genuinely curious how many people have a tested fallback versus a theoretical one.