An open model instead of a Claude plan

The short answer

Running an open model instead of a Claude plan works for some jobs and fails for others, and the split is predictable. An open-weight model is one whose weights you can download and run yourself. Those models now read long documents and draft text in your own language well enough that many people stop paying for that work. They run a coding loop under supervision. They do not cover the hardest reasoning, and they are not free, because a GPU (graphics processing unit) server billed by the month often costs more than the subscription it replaces. Buy the plan if you can. This page is about what runs on hardware you control if you cannot, or if the plan is not worth its price to you.

What the plans cost, and what you would be replacing

As of August 2026, Claude Pro is $20 per month, or $17 per month when you pay for a year up front. Max starts at $100 per month and sells two usage levels above Pro. Team is $25 per seat per month, or $20 per seat billed annually. A free tier exists with tighter limits. Those are the prices. The reasoning behind them belongs on the pages that own it: which plan you would need compares the tiers by usage rather than by price, the Pro page covers where its limits actually bite, and what Claude Code costs on each plan is the one to read if the work is coding.

If the monthly subscription is the part that does not fit, look at paying per token instead of per month before you look at hardware. The API (application programming interface) has no monthly floor, so someone who uses an assistant two hours a week can pay less than any subscription costs. Input and output tokens are priced separately, which is what makes that arithmetic worth doing rather than guessing.

Be clear about what leaving costs you. A hosted frontier model keeps a long chain of dependent steps coherent, and it recovers from its own tool errors instead of getting stuck. Moving to your own box trades that away for a fixed monthly bill with no per-message limit and for data that never leaves your machine. It also pins the model version, which matters once you have tuned prompts around one.

Judge the swap by task, not by leaderboard

A benchmark table ranks models on an average over tasks that are not your tasks. A model can win a coding benchmark and still be the wrong choice for reading contracts in Russian. So split your own use into jobs and judge each one separately. Four jobs cover most of what people pay a subscription for: an agentic coding loop, reading long documents, translation and drafting, and hard reasoning on unfamiliar problems. The first three have workable open answers today. The fourth does not.

Can an open model run an agentic coding loop?

An agentic loop means the model reads files, runs a command, reads the output, and edits again, many times, without you approving each step. An open model can run one, but it needs supervision, and the reason is arithmetic rather than opinion. Errors compound along the loop, because each step's mistake becomes the next step's input. A model that is right nine times out of ten on a single step is wrong more often than not after twenty steps. A hosted frontier model does not escape this. It starts from a higher per-step number, and that advantage grows with the length of the loop. So the local version of this job is short loops with a check at the end: one file, one function, one failing test that has to pass.

Two models are where most local coding setups land. Install Ollama, then pull one:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3-coder

qwen3-coder is published as a 30B mixture-of-experts model with 3.3B parameters active per token and a 256K context window. ollama run devstral gives you Mistral's 24B agentic coding model under the Apache 2.0 licence, published with a 128K context window. Those are the vendors' published figures, not measurements of ours. For what each one needs from your hardware and at which quantisation (quantisation stores the weights at lower precision, which shrinks the model and costs some accuracy), the models you can actually self-host carries the measured side, and running a Qwen 3 model on a VPS is the step by step.

Ollama exposes an OpenAI-compatible endpoint at http://localhost:11434/v1/, so most coding tools point at it by changing one base URL. The client library still demands an API key field; the server ignores the value. Expect good results on a bounded request: write this function, convert this config, explain this stack trace, write the tests for this file. Expect weak results on the open-ended one: find why this breaks somewhere in these forty files. That second shape is exactly the long loop where per-step errors pile up.

Reading long documents on your own machine

This is the job where a local model comes closest to a paid one, because the work is finding and condensing what is already in the text rather than inventing something new. It is also the job with the clearest reason to keep the data at home: contracts, medical records, internal reports, and anything covered by a non-disclosure agreement.

The trap here is the context window, and it fails silently. Ollama's default context window is 4096 tokens. Feed it a 40-page document and everything past that limit is dropped before the model ever sees it, so you get a fluent summary of the first few pages and no error anywhere. Set the size explicitly:

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

The same value can be set per request as num_ctx, or interactively with /set parameter num_ctx. A published context window is a ceiling, not a promise. Memory use grows with the KV cache (the stored keys and values for every token so far), so a long input eats the GPU memory left over after the weights, and the process dies or spills to system memory and crawls. Accuracy also falls for facts sitting in the middle of a very long input. The practical answer is to split the document, ask per chunk, and combine the answers yourself.

Translation and drafting, tested in your own language

This is the strongest case for an open model, and the case where English benchmarks tell you the least. Test in the language you actually write in. Most tokenizers split Cyrillic text into more tokens per word than the same text in English, so a Russian document fills the context window sooner and generates more slowly than an English one of the same length. That is a property of the tokenizer, not a verdict on the model's skill.

Build a fixed test set before you compare anything. Twenty real documents from your own work, each with the output you would accept. Run every candidate against the same twenty and read the results yourself. Nobody's leaderboard can measure this for you, because it turns on your domain vocabulary and your register.

Russian-language fine-tunes of open models exist and are published openly, the Vikhr family among them. Do not assume a specialised fine-tune beats a current general model. A newer multilingual base is often better in Russian than an older model tuned for Russian, because the base improved by more than the tuning added. Run both against your twenty documents and let that decide.

Where the gap does not close

Hard reasoning is the job worth keeping a paid option for. Long chains of dependent steps, design decisions inside code you did not write, and problems where the requirements themselves are ambiguous are where a smaller open model fails in the most expensive way. It stays fluent and confident while the middle of the answer is wrong. A wrong answer that reads well costs more than no answer, because you have to check every line to find the break.

The setup that works is a split. Volume goes to the model you run. Hard cases go to a pay-per-token key called a few times a month, which costs very little at that rate, and picking the right model for the job matters more there than anywhere else. If you are on Max mainly for the limits, work out what you actually use first, because that decision and this one are the same decision.

What the hardware really costs each month

Here is the part that settles it. A GPU VPS billed monthly charges for the whole month whether you run it for five hours or five hundred. There is no idle discount. A GPU instance also rents for a good deal more per month than a Pro subscription costs, so the swap starts behind and has to catch up. Take the monthly rate of the instance you would actually buy and divide it by the plan price. If the answer is 5, then the swap must buy you something a subscription cannot sell you: data that stays on your machine, or an agent that runs all night with no per-message cap. The break-even between a GPU VPS and API tokens carries the formula and worked examples, and the same arithmetic holds with a monthly plan price in place of the token bill.

Two ways to move the numbers. Rent by the hour and stop the instance when the job ends, which suits batch work; check whether your provider still bills for the disk while an instance is stopped, because that is the charge people forget. Or run a smaller model on an ordinary CPU VPS with no GPU bill at all. CPU generation is slow enough that an interactive coding loop is unpleasant, but nothing is waiting on an overnight job that summarises 400 documents. What an ordinary VPS costs sets that floor.

Serving it: Ollama first, vLLM when there is more than one user

Start with Ollama because it is one command, it fetches and runs the model, and it speaks the API your existing tools already use. In practice it serves one person at a time. When several people or several agents hit the same box, switch to vLLM, which batches requests and keeps the GPU busy instead of idle between prompts:

uv pip install vllm --torch-backend=auto
vllm serve Qwen/Qwen2.5-1.5B-Instruct

Swap in the model id you chose. vLLM listens on port 8000 and serves the same OpenAI-compatible shape, so nothing above the base URL has to change when you move.

One security point, because it is the mistake that gets these servers found. Ollama binds to 127.0.0.1 on port 11434 by default and has no authentication of any kind. Set OLLAMA_HOST to 0.0.0.0 on a machine with a public IP and you have published an unauthenticated model server to the internet, where anyone scanning that port can spend your GPU time and read whatever your tools send through it. Keep it on localhost and reach it over an SSH tunnel or a VPN, or put a reverse proxy in front of it that demands a credential. vLLM on port 8000 needs the same treatment.

Once it answers on a port, the rest is ordinary plumbing. Building your own agent on a VPS and driving one from an n8n workflow both work against a local endpoint, because they need a base URL and a model name and nothing else.

How to decide in one week

1. Write down the jobs you really use an assistant for, with one concrete example of each.
2. Run those examples on what you have now, including the free tier, and save the answers.
3. Rent a GPU server by the hour for one evening, serve one candidate model, and run the same examples through it.
4. Compare the monthly cost against the saved answers, not against a benchmark table.

Most people who run that week end up splitting the work rather than switching. The volume moves to a model they host, the hard questions stay on a paid API, and the monthly bill falls without the quality of the hard answers falling with it.

FAQ

Can an open model replace Claude Code for daily coding?

For short, well-scoped tasks, yes. Write a function, convert a config file, explain an error, generate tests: a local coding model handles these, and it points at your editor through the OpenAI-compatible endpoint at http://localhost:11434/v1/. It is weaker on long autonomous loops across many files, because each step's error feeds the next step and the loop drifts. Keep the tasks short, keep a test to check against, and read every diff.

Which open model should I run first?

For code, ollama run qwen3-coder or ollama run devstral. For general text and translation, start with a current general model such as gemma4 or qwen3.5, in the largest size your hardware serves at a speed you will tolerate. Then stop reading model cards and run your own twenty documents through each one, because your language and your domain decide this, not the vendor's table.

Is a GPU VPS cheaper than a Claude plan?

On price alone, usually not. A monthly GPU instance costs several times a Pro subscription and bills the same whether you use it or not. It wins when you need something the subscription does not sell: data that never leaves your machine, a job that runs all night with no message cap, or a fixed bill that does not move with usage. Run the numbers with the formula on the break-even page before you rent anything.

Will a local model handle Russian as well as English?

Current multilingual open models draft and translate Russian at a useful level, but two things differ from English. Most tokenizers use more tokens per word for Cyrillic, so the same document fills the context window faster and generates more slowly. And English benchmark scores do not transfer, so a model that leads an English table can be the weaker choice for your Russian text. Test with your own documents, and compare a Russian fine-tune against the newest general model instead of assuming the fine-tune wins.