Skip to main content
All articles

Industry

Getting off one AI subscription

Six weeks of quota limits, credit running dry and one bad switch taught me that the goal isn't leaving a provider. It's never depending on any single one.

Adrian Shedden10 min read

On 6 October I typed a message to my AI setup that I won't reproduce here. The polite version is: get me off Claude, now. An hour later I'd changed my mind about what I meant. I didn't want to leave Claude. I wanted to stop depending on it, or on any one provider, for work that has to keep moving.

That distinction took me about six weeks of things running out to understand. This is the dated record of those weeks, what broke, and where I've ended up.

A bit of context first. I run my consultancy, my legal work and a fair bit of my life through an AI operating system I've built over the past year. Since late July a set of AI agents I call the factory picks up tickets (written jobs), builds them, checks its own work and hands it back to me. I wrote about how that started in Building the metafactory. All of that runs on AI models, and models come from providers, and providers have limits.

31 August: the first wall

The first time it bit properly was the end of August. I hit the weekly usage limit on my main Claude subscription and everything stopped until it reset.

I did two things that day. I bought a second, smaller Claude subscription so I had somewhere to keep working, and I set up ChatGPT with Codex, OpenAI's coding agent. The Codex account wasn't just spare capacity. I used it straight away to review the factory against the published work I'd built it from, because I wanted a second opinion from a different lab before I let the factory run again.

That second opinion turned out to matter more than the capacity. It was the start of a rule I now hold firmly.

18 September: one family makes, another judges

By mid-September the factory had a clear shape. One model builds the work. A different model checks the plan and reviews the result. On 18 September I wrote it down as a rule: one model family makes, a different family judges.

The reason is simple. A model is quite good at spotting another model's mistakes and quite bad at spotting its own. If the same family builds and reviews, the review tends to agree with the build.

The same afternoon, OpenAI's tokens ran out. Codex was at zero and wouldn't reset until the next evening. Under the old setup that would have meant the factory either stopped judging or let Claude judge its own work. Instead I moved the judging to an open model (one whose weights are published, so lots of companies can run it) through OpenRouter, a service that gives you one account for dozens of models. The pick wasn't a name off a list. It had to pass the same checks Codex had passed before it went live: start fresh, resume, use tools, respect permissions, return a result, and survive a real review on a live ticket. GLM 5.3 got the job.

19 September: what the end state looks like

The next day I set out where I wanted to get to. One top-tier account each at two labs for the work that really needs the best models. Everything else on cheaper or open models, picked as the work comes in, at the cheapest route that's good enough.

I refined it the same day into something closer to a measure I can check: use most of every subscription I already pay for, never run out, and spend as little extra cash as possible while keeping a floor on quality.

The other decision on 19 September was about privacy, and I'd put it first if I were starting again. Every model route the factory or my system uses must default to no data retention and no training on what I send it. Any exception has to be approved by me and recorded against that route. The big subscription services got that approval on 1 October. Later, so did one coding tool's subscription, on the same basis. One cheap tier I looked at was rejected outright because the price came with training on your data. Cheap isn't cheap if the cost is your clients' information.

1 to 2 October: the credit runs out

On 1 October OpenRouter started returning a "payment required" error. The credit had run dry. Worse, the factory was still sending plan checks to it whenever its usual route was busy, so they failed. The fix that day was to take OpenRouter out of the fallback list entirely until it had credit, and rely on subscriptions only.

The next day Codex was out until 7 October on its weekly limit. That left Claude building and Claude reviewing, which breaks the two-families rule. I topped up OpenRouter with £40 so an open model could stay the independent checker for anything Claude built. Small amounts, but they show the pattern. Every route runs out eventually. The question is whether something else is ready when it does.

3 to 6 October: the WhatsApp test

My main way of talking to my AI is WhatsApp. I message a group, it replies. Until October that only worked if Claude was answering. On 3 October a driver went in that lets those groups answer on any model, with the same reply rules and the same routing checks whichever model is behind it.

That raised the obvious question: which models are actually good enough? On 6 October I ran a blind test. Each model answered the same set of real-style messages, and an automated judge scored the answers without knowing which model wrote them. The results:

  • MiniMax M3 scored 2.66 out of 4 and came top.
  • GLM 5.3 scored 2.36 out of 4 and had the best tone.
  • DeepSeek V4 Pro replied in Spanish or Italian on 3 of the 8 messages, so it went no further.

From those results I set up tiers. Routine messages go to the cheapest model. Normal chat goes to GLM 5.3. Anything that's a direct question, or where someone is clearly having a hard time, goes to MiniMax M3. If those fail, a small free model on my own server answers as a last resort. The prices, per million tokens (roughly, per 750,000 words), were recorded on 3 October: MiniMax M3 at $0.30 in and $1.20 out, GLM 5.3 at $0.07 in and $7.00 out, DeepSeek V4 Pro at $0.21 in and $0.42 out.

The bar I set was "good enough, a bit below Claude". I didn't need the open models to be better. I needed them to be there.

6 October: the message I sent, and the one I meant

The evening of 6 October was when I lost patience. Quota was low again, and I'd had enough of everything waiting on one company's weekly reset. That's when I sent the message I won't print. The factory did what I asked. Every seat (each role in the factory, like builder or reviewer) moved off Claude: building to Codex, reviewing and checking to MiniMax M3 through OpenRouter, Claude only as the last fallback. OpenRouter had $4.07 left.

An hour later I asked myself a better question. Why would we move away from Claude models while I still had subscription quota left to use? I was already paying for it. So I corrected the instruction. "Off Claude" means not reliant on any one subscription. Route by how much quota is left and by cost for the quality needed, and use the subscriptions first. The seats were put back in that order.

Then a third decision, the most useful one: no new spend. No OpenRouter top-up, no new subscription. Get the work done with what I have. When it runs low, the factory waits. That sounds like a step backwards, but it forced the routing to get smarter instead of me paying my way round each shortage.

7 October: switching everything at once

The next morning the factory's supervisor moved every Claude seat to Codex in a single change. It passed the factory's own checks for a valid setting. It didn't pass the real world.

Two lanes broke straight away. Discovery (the stage that asks me questions about a new ticket) couldn't start Codex inside its sandbox at all. And every fresh build was refused, because the planner now ran on a model the builder's own re-check didn't accept. About two hours of work was lost before anyone noticed, while Claude quota sat at 97% used.

The root cause is a mistake I'd make in any business. A settings check tells you the change is well-formed. It doesn't tell you the work still runs. The rule now: after any change to which model does what, put one real ticket through each changed lane and watch it actually start, before moving the next lane. One at a time, with a canary (a small test case that tells you if something's wrong) for each.

8 to 9 October: everything runs out together

8 October was busy. I've written about the day in Building from a van while the factory ships. The provider part of it goes like this.

In the evening Codex hit its usage limit, with no reset until 14 October. The seats moved back to Claude for building, with OpenRouter for review. Then at 06:55 the next morning the factory reported it had no working lane at all. OpenRouter had $0.05 left, $129.95 used of $130. The review, discovery and priority seats all defaulted to it.

That report was wrong, and the correction at 07:09 is worth noting. One lane was still working: a Claude review was running at that moment on my main subscription. So the true picture was narrower but still uncomfortable. The cheap lanes were gone, Codex was gone for six days, and everything had fallen back onto one Claude subscription. Exactly the dependency I'd been trying to get rid of.

It also showed me where the real weakness was. Each ticket had its model written into it when it was set up. When a route died, someone had to rewrite tickets by hand to move them, and even then some refused to move. That's ticket #334, still open as I write: the model gets chosen when the work is sent out, based on what's available and what it costs, instead of being fixed into the ticket.

12 October: WhatsApp moves itself

The WhatsApp side is further along. Since 6 October I'd asked for model switches there to be manual, with reminders, because those groups include family and I wanted to know what was answering.

On 12 October that changed to automatic. Every five minutes my server checks for a group message that's gone three minutes without an answer, or for a login or quota error. If it finds one, it moves to the next working option, from my Claude accounts to Codex to the open models, and posts one line in my main group saying which one is now answering. The family groups stay on Claude as long as any Claude account works. When Claude is healthy again, it moves back.

That's the shape I want everywhere. Not loyalty to a provider, not hopping between them for the sake of it. A preferred route, known fallbacks, and an honest line telling me when it's switched.

One rule I had to say four times

There's a small lesson in here about quota that cost me more than it should have. My subscriptions are different sizes. A larger plan at 60% used has far more left than a smaller plan at 60% used. The supervisor kept comparing the percentages as if they were the same thing, and making bad calls about which account to use. I said it four times before it went into the hand-over rules in writing: never compare percentages across different-sized plans. Hand over to a fresh session at 75% of its working memory, and stop before 95% of the weekly ceiling.

It sounds obvious. Most quota mistakes are.

If you're doing this yourself

You don't need a factory for any of this to apply. If your business has started to lean on one AI tool, here's what I'd do, in order.

  1. Write down what you'd do if it stopped tomorrow. Which jobs would wait, which would need a person, which could run on something else. That list is your real dependency.
  2. Set your privacy rule before you add a second provider. Check whether each one keeps or trains on your data, and decide your default. Cheap options often pay for themselves with your data.
  3. Test the alternatives on your own work, blind if you can. Generic rankings won't tell you that a model answers in the wrong language a third of the time.
  4. Use what you already pay for first. Subscriptions you've paid for are the cheapest capacity you have. Extra spend should be the fallback, not the default.
  5. Switch one thing at a time and watch it work. A setting that saves without error isn't proof. A real job completing is.
  6. Make the switch visible. If something changes which tool is doing your work, you should get one plain line telling you.

Where this leaves me

As of today, 13 October, I'm not off Claude and I don't intend to be. It still does most of my building and most of my conversations, because it's the best tool I have for that and I'm paying for it. What's changed is that it's no longer the only route. The WhatsApp groups move themselves. The factory's judges come from a different family to its builders. Privacy is a default, not an afterthought. And the one piece that still ties a job to a single model, #334, has a ticket and a plan.

If you're working out how much of your own work rests on one AI subscription, I'm happy to think it through with you.

Get articles like this in your inbox

Practical AI for small UK businesses. One idea you can use, each week. Unsubscribe any time.

Want to talk about this? Let's see if we should work together.