Leaving paid AI tools, one tool at a time

Most people who want off paid AI tools stall at the same place. They like the idea, they are tired of the stack of subscriptions, but cancelling feels like jumping without a net. What if the open-source version is worse? What if a workflow breaks mid-project? For a business, the question underneath is how much each cancelled tool saves a month and what, if anything, the team gives up.

The method below removes the jump. You do not cancel anything until you have watched a local replacement do the same job, side by side, on your real work. Inventory, map, run in parallel, then cancel what proved replaceable. It is slower than a clean break and far more honest, because the decision to cancel is made on evidence, not hope.

We are not going to invent a dollar figure for what you will save. Your savings depend on which subscriptions you hold. What we can give you is the sequence, and the record of how it went when we used it on ourselves.

What do you need before you migrate?

You need one foundation in place: a way to run open models locally. Here that is Ollama, the first tool we install on any machine. It downloads and serves open models with one command, and it speaks the same API shape as the big cloud providers, so the tools you migrate to can point at it directly. If you have not set it up yet, do that first; the rest of this guide assumes a model is running locally at http://localhost:11434.

When we made the move, we would not touch a single tool until that engine answered a question with the Wi-Fi off. With the engine proven, every later step became “point a tool at the thing we already have” rather than “build something new.”

You also need a tolerance for “good enough.” The goal is not to prove the open-source tool matches the paid one on every edge case. It is to confirm it handles your actual work. Those are different bars, and the second one is the one that pays your bills.

How much machine does a local stack need?

Size the machine to the work. For a brainstorming partner, a 7B or 8B parameter model is enough. Complex system design or deep research pushes you towards 30B or 70B models. A 31B model runs on our 48 GB test machine; 70B models need more memory than that. Models quantised to 4-bit or 8-bit, from families such as Llama and Qwen, give the most capability for the memory they take.

Our own measurements give part of a sizing answer. On our test machine, an M4 Pro with 48 GB of unified memory, the Gemma 4 31B file of 18.85 GB ran as a 21.97 GB process at 8,192 tokens of context and 25.24 GB at 65,536, in our context window test. A second large model fitted beside it, but when two generated at once the faster one lost 65 percent of its speed in our two-model test. On that result, one model generating at a time per machine is the only arrangement our tests support.

The 31B model wrote about 11 tokens a second on our test machine. A mixture-of-experts model wrote about 50 a second in our Qwen3.6 35B-A3B vs Gemma 4 31B test, and finished fewer answers.

Apple’s UK Mac mini page, read on 17 October 2026, lists configurations from 16GB to 64GB of memory and no longer lists the M4 Pro. Size against the memory figures above rather than the chip name: the model file, plus the context, plus whatever else the team keeps open. Our RAM sizing guide covers the arithmetic.

How do you migrate from paid AI to open-source?

Step 1: Inventory what you are paying for

Open your subscriptions and write down every AI tool you pay for. Bank statement, app store receipts, the renewal emails you have been ignoring. For each one, note what it is, what you actually use it for (the job, not the feature list) and how often you reach for it.

The “what you actually use it for” column is the important one. People pay for a sprawling tool and use a tenth of it. A subscription you open twice a month to summarise a PDF is a very different migration than the assistant you live in all day. Be honest about frequency, because it tells you which migrations are worth real effort and which are nearly free wins.

Step 2: Map each one to a local replacement

Now match each job to an open-source tool that runs on your own machine. The pattern that holds across most stacks:

• A cloud chat assistant becomes Open WebUI plus Ollama. A polished chat interface in your browser, pointed at a model on your disk. Same shape of interaction, no round-trip to a server, no per-message metering. This covers the largest single category for most people: the general chat tool they default to.
• A paid coding assistant in your editor becomes OpenCode plus Ollama. OpenCode ships as a normal desktop app and points at your local model, giving you an agent that reads, edits, and runs code with nothing leaving the machine. It is the open answer to the proprietary desktop coding tools, and it pairs naturally with the local model you already have running.
• Paid transcription becomes WhisperX. Audio and video to text, run locally, no upload step and no per-minute charge.
• Cloud document Q and A becomes AnythingLLM. Ask questions of your own files against a local model, instead of handing your documents to someone else’s server.

Map every line from your inventory to a replacement before you install anything. Some will map cleanly. A few may not have a one-to-one local equivalent yet; mark those honestly and keep them for now. The point of the map is to see the whole picture before you move, not to force every tool across on day one.

Then rank the jobs by risk, not by price. We moved from least scary to most scary, so that each success bought confidence for the next. Everyday chat and drafting went first: if a local chat tool produced a worse email draft, the cost was a slightly worse email. Coding came next, handled carefully, because code is the thing we least wanted leaving the building, which made it both the most valuable swap and the most nerve-wracking. Transcription for documentary work and document Q and A came after that, in their own time.

Step 3: Install the replacements alongside, not instead

Install the open-source tools while your paid subscriptions are still live. This is the part that removes the risk. You are not switching; you are adding a candidate next to the incumbent.

Because each replacement points at the same local model, you set the foundation once and reuse it. Open WebUI, OpenCode, and a documents tool all talk to the same Ollama endpoint. There is no separate engine to stand up for each one.

Keep both tools reachable during this phase. The paid one stays your safety net. The local one is on trial.

Step 4: Run them in parallel on real work

This is the trial, and it is the heart of the method. For a set period, a week or two of normal work, do the job in the open-source tool first and keep the paid one as backup.

Drafting an email? Write it in Open WebUI against your local model. Fixing a bug? Hand it to OpenCode first. Transcribing an interview? Run WhisperX before you reach for the cloud service. Only fall back to the paid tool when the local one genuinely cannot do the job, and when you do, write down what stopped it.

That log of fallbacks is your decision-maker. At the end of the trial you will have evidence, not impressions. Maybe the local chat tool handled everything and you never opened the paid one. Maybe the coding agent covered your day-to-day but you reached for cloud on two genuinely hard problems. Maybe a tool simply was not ready. Each outcome tells you exactly what to do next.

In our own move, the parallel period did two jobs. It showed us the places where the local version actually fell short, instead of leaving us to guess at them. And it let trust build at its own pace, which for some jobs was a day and for others was a couple of weeks.

Step 5: Cancel what proved replaceable

Now cancel, one subscription at a time, on the strength of the trial. If the local tool carried your real work for two weeks, cancel its paid counterpart and keep going. If a tool fell short on something you do often, keep that subscription for now and revisit later; open-source tools move fast, and one that missed this quarter may clear the bar next quarter.

The rule we used to end each parallel run was simple: a subscription came off the bill only after a full normal week in which we never reached for it. Not after it felt good in a demo. Record the date each one is cancelled, so the saving at the end is measured against your own bills.

Cancel deliberately, not all at once in a burst of enthusiasm. One cancellation per proven replacement keeps the whole thing reversible and calm. You are trimming what the evidence says you no longer need, and leaving in place what you still do.

How do you prove a local tool replaced the paid one?

The clearest proof is the trial itself: a week of real work done locally, with a short log of the rare moments you had to fall back. If that log is mostly empty for a given tool, the migration is real, and you can cancel with confidence.

A second, quieter proof is worth doing once. With a model pulled, turn off your Wi-Fi and use one of your new local tools. It answers. Nothing left your machine. That moment is the whole reason this migration is different from swapping one cloud subscription for another: the work now happens on hardware you own.

On our side, the move produced less drama than we expected. The coding, drafting, transcribing and document work feels the same on a normal day. We did not get slower. Three things around the work changed. Nothing leaves the building, so nobody runs a small risk calculation before pasting client code into a tool. The monthly bill stopped growing as we added tools, because adding a tool now means pointing it at an engine we already run. And the work kept going during an outage, on a flight and in a cabin with no signal.

What are the trade-offs of replacing paid AI tools?

The model is the ceiling. A local tool is only as good as the model behind it. For most daily work a solid local model is enough, and the privacy and the absent bill change the calculation. For the hardest tasks, the best cloud models can still be ahead. We found that on the hardest coding problems: a frontier cloud model was still ahead, so we kept a cloud option for that single class of problem and use it on purpose, not by reflex. Keeping one paid tool for those cases is a legitimate choice, not a failure of the method.

Parallel running takes discipline. The trial only works if you actually reach for the local tool first. It is easy to default back to the familiar paid one out of habit and never give the replacement a fair test.

Not every tool has a clean local twin yet. Some niche paid tools do not map one-to-one. Mark those, keep them, and recheck periodically rather than forcing a bad substitute.

You take on some maintenance. Local tools update, models get better, and you are now the one who keeps things current. In our case it has been far less work than we feared, but it is not zero. For most people that is a fair trade for ownership and no monthly bill. For some it is not, and that is worth knowing about yourself before you start. Disk and memory are yours to manage too: models are large and live on your drive, so size them to your machine and clear out what you no longer use.

What does renting leave you exposed to?

The other side of the trade is what a subscription does not show on the invoice. When you rent, you rent your uptime: when the service is down, your work is down. The vendor writes the terms for pulling your own history and outputs, and can rewrite them. A feature you built a workflow around can be changed, throttled or retired. What leaves your machine lives under someone else’s policy, which is why we treat local AI privacy as something you prove rather than promise.

The published terms say more about what renting will cost later than the price does, and they can be read in an afternoon before a workflow depends on them. Start with the retirement policy. Anthropic’s model deprecations page, read on 17 October 2026, says the company gives customers with active deployments “at least 60 days’ notice” before a publicly released model is retired, and that requests to a retired model fail. Sixty days is the window a team has to retest every prompt and workflow on the replacement. If a product depends on one model’s behaviour, put that retest in the plan now rather than when the email arrives.

Then ask what the notice does not cover. In June, a US export-control order made Anthropic switch off Claude Fable 5 and Claude Mythos 5 for every customer on the afternoon the order arrived, and access returned 18 days later. No deprecation policy was involved. A rented model can stop for reasons neither the vendor nor its customers control. A model file on your own disk has no retirement date.

Last, read what happens to your data and whether your history can be exported. Those clauses decide how expensive leaving becomes once the tool sits inside daily work. The longer you build on a rented tool, the more of your workflow assumes it, and by the time the terms change in a way you dislike, switching is its own project.

Renting still wins in places. A managed service takes the uptime and the updates off your hands, and for some teams on some workloads that handoff is worth more than control. The frontier of raw capability is also still rented territory, which is why we keep one cloud model for the hardest jobs, the same split we draw in stop paying monthly for AI.

What do you save per tool when you replace paid AI tools with open source?

The saving per tool is its list price times the seats you cancel. The table lists published prices for paid tools in three of the jobs this guide maps, from the vendors’ published prices on 17 October 2026. They are list prices for one person; an invoice may differ with discounts, annual terms or extra usage.

Across those three, one person’s list prices come to about $55.99 to $66.99 or more a month (19 to 30, + 19.99 + 17), or $671.88 to $803.88 or more a year. Cancel a tool for a team and the figure multiplies by the seats, the compounding we set out in what per-seat AI pricing costs a business.

To cost the move for a business, list every AI subscription it pays for, with the per-seat price from the vendor’s own pricing page and the number of seats, and multiply out the annual cost of each. That list is the most that can come off the bill. Against it, put the local side: check whether your existing machines have the memory for the models each job needs. Any machine that falls short is a hardware line in the budget, and so is the time of whoever owns upkeep.

The other half of the question is what quality you lose, and our record is thinner than a table can carry. Our own move found one clear loss: on the hardest coding problems a frontier cloud model was still ahead, and we kept a cloud option for that class of problem. We did not record our subscription costs before and after the move, or the hours of upkeep each month, and we did not keep a per-tool fallback log, so we cannot give a measured saving or a quality score for each tool from our own move. That needs our invoiced amounts and a fallback log kept through a fresh parallel run, and it is on our list. We have also not timed a creative team’s week on this stack, task by task, so we make no claim about hours saved. The fallback log in step 4 is how a team gets those numbers for itself.

Where do you go after migrating?

If you are not ready for a full migration, own one piece first. Take the capability you would least like to lose, stand up a local version, and run it for a week alongside the subscription. Transcription or autocomplete is a good first piece, because both run comfortably on a laptop and neither needs the frontier.

Once the first migration sticks, the natural next move is to deepen the stack you kept: a better local model for the jobs you do most, the same model wired into your editor for autocomplete, or a documents tool pointed at your own files. Each reuses the local foundation you set up here, so every addition gets cheaper. For the memory constraints and model choices behind our own setup, see how we built our local AI stack.

You now have a way to leave paid AI tools without guessing: prove the replacement on real work, then cancel what it covered.