Can you self-host Claude? The honest answer

Can you self-host Claude? No, and here is why

You cannot self-host Claude. Anthropic does not publish the model weights, so there is no file to download, no container to run, and no licence that would let you serve it from your own hardware. Every Claude request goes to Anthropic's API or to a hosted partner such as Amazon Bedrock, Google Vertex AI, or Microsoft Foundry. Running it on a machine you own is not a configuration problem. The artefact simply does not exist outside Anthropic.

That is the short answer. The longer answer is that most people asking the question do not actually want the weights. They want one of three things that are all achievable on a server you control: a capable model running locally, a gateway that holds their API keys and caps their spend, or a coding agent that lives on their own box instead of their laptop. This guide covers all three, with the commands.

What "self-hosted Claude" usually means

Search traffic for "self hosted Claude" splits into a few different wishes, and they need different answers.

Some people want privacy. They do not want prompts leaving their network. Only a local open weight model solves that, because any Claude request is by definition a request to Anthropic.

Some people want cost control. They are worried about a runaway agent burning through credits. A gateway solves that, and it works with Claude, so you keep the model quality.

Some people want independence from a laptop. They want an agent that keeps working while they close the lid. A VPS solves that, and Claude Code runs on it happily.

Some people want the phrase "self hosted OpenRouter". That is a gateway too, and the usual answer is LiteLLM.

Work out which one you are, because the right build is different in each case.

Self-host an open model with Ollama

If the requirement is that no prompt leaves your server, run an open weight model. The families that are actually usable on a rented server today are Llama, Qwen, Mistral, Gemma, and DeepSeek. All of them publish weights you can download and run.

Ollama is the fastest way in. The install script is one line, and it sets up a systemd service on Ubuntu.

curl -fsSL https://ollama.com/install.sh | sh
systemctl status ollama

systemctl status ollama should print active (running). Then pull a model and talk to it.

ollama pull qwen3:8b
ollama run qwen3:8b "Summarise what a reverse proxy does in two sentences."

The first pull downloads several gigabytes, so the model has to fit in RAM or in GPU memory before it can answer anything. A rough rule for quantised models: an 8 billion parameter model needs about 6 GB free, a 14 billion parameter model about 10 GB, and a 70 billion parameter model needs more memory than most general purpose VPS plans carry. If the box is short of memory the process is killed by the kernel and you see Error: llama runner process has terminated, with an out of memory line in dmesg. Check free -h before blaming the model.

Ollama also serves an HTTP API on 127.0.0.1:11434, which is what makes it useful to other software rather than just a chat toy.

curl http://127.0.0.1:11434/api/generate -d '{"model":"qwen3:8b","prompt":"ping","stream":false}'

Leave that port bound to localhost. An open Ollama port on a public IP is a free GPU for whoever finds it. The full build, including the systemd unit, GPU detection, and putting a reverse proxy in front, is covered in the guide to running Ollama on a VPS. If you are serving more than one user at a time, read the comparison of Ollama and vLLM first, because Ollama's single stream design becomes the bottleneck well before the hardware does.

Be honest about the gap. A good open model on a mid sized VPS is genuinely useful for summarising, classifying, drafting, and simple extraction. On long multi step reasoning, on large codebases, and on agentic tool use it is not close to a frontier hosted model, and no amount of prompt tuning closes that gap. Pick the local model for the work it is good at, and pay for the hosted one where the difficulty is real.

Run your own gateway with LiteLLM

This is the "self hosted OpenRouter" people are searching for. A gateway sits between your applications and every model provider. Your apps hold one key, pointed at your server. The real provider keys live only on that server. You can cap spend per key, route different apps to different models, and log every request in one place.

LiteLLM is the common choice because it speaks an OpenAI compatible API and proxies to Anthropic, to Ollama, and to most other providers behind the same endpoint. Run it in Docker with a config file.

model_list:
  - model_name: claude
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: local
    litellm_params:
      model: ollama/qwen3:8b
      api_base: http://127.0.0.1:11434

Save that as litellm_config.yaml and start the proxy. It listens on port 4000.

docker run -v $(pwd)/litellm_config.yaml:/app/config.yaml \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  -e LITELLM_MASTER_KEY=sk-1234 \
  -p 4000:4000 docker.litellm.ai/berriai/litellm:latest \
  --config /app/config.yaml

LITELLM_MASTER_KEY is the admin credential, so treat it like a root password and do not ship the example value. Call the proxy exactly as you would call a hosted API.

curl http://localhost:4000/v1/chat/completions \
  -H 'Authorization: Bearer sk-1234' \
  -H 'Content-Type: application/json' \
  -d '{"model": "claude","messages": [{"role": "user","content": "Say hello in five words."}]}'

A healthy response is normal JSON with a choices array. A 401 means the Authorization header does not match your master key. A 400 naming the model means the model in your request does not match any model_name in the config file.

The reason to build this rather than call Anthropic directly is the spend cap. Issue a separate virtual key per application, each with its own budget.

curl 'http://0.0.0.0:4000/key/generate' \
--header 'Authorization: Bearer sk-1234' \
--header 'Content-Type: application/json' \
--data-raw '{"models": ["claude"], "max_budget": 100}'

That key can spend one hundred dollars and reach one model, and nothing else. When an agent misbehaves at three in the morning, the blast radius is one key rather than your whole account. That pattern, plus the monitoring around it, is the subject of keeping agent costs under control on a VPS. If you are still deciding whether to pay per token at all, the API versus subscription cost comparison works through the arithmetic.

Note what the gateway does not do. It does not make Claude local, and it does not hide your prompts from Anthropic. Requests still leave your server for the provider. What you gain is control over keys, spend, routing, and logs.

Run Claude Code on your own VPS

The third wish is the easiest one to grant. Claude Code is a client. It runs wherever you install Node.js, and it talks to the API over HTTPS. Putting it on a server you own means the agent keeps working after you shut your laptop, and it means the agent's blast radius is a box you can rebuild rather than your main machine.

npm install -g @anthropic-ai/claude-code
claude --version

Run it inside tmux so a dropped SSH connection does not kill a long job. That setup, including the session handling, is covered in running Claude Code on a VPS with tmux. Give the agent its own unprivileged user, and read the safety rules for running Claude Code on a server before you hand it write access to anything you care about.

This is self hosting the agent, not the model. It is worth being precise about that, because it is the part people conflate. You own the process, the filesystem, the network egress, and the logs. Anthropic still owns the inference.

What each option actually costs you

Prices move, so treat these as a shape rather than a quote. As of July 2026, Claude Sonnet 5 lists at $3 per million input tokens and $15 per million output tokens, and Claude Opus 5 at $5 and $25. A local model costs nothing per token, and instead costs whatever the server costs per month, running whether you use it or not.

The break even point is lower than people expect. A VPS with enough memory to run a useful open model costs real money every month, and it sits idle most of the time. If your usage is bursty, the hosted API is usually cheaper. If your usage is constant, or if your data cannot leave your network, the local model wins on both counts.

The honest mixed answer is the one most teams land on. Run an open model locally for the high volume, low difficulty work. Route the hard requests to a hosted frontier model. Put a gateway in front of both so the applications do not need to know which is which, and so you can move the line between them without touching application code. That architecture is the practical version of "self hosted Claude", and unlike the literal version, it exists. If you want to run the whole agent stack yourself as well, the roundup of self-hosted AI agents covers what is available.

FAQ

Can I download Claude's model weights and run them locally?

No. Anthropic has never released weights for any Claude model, and there is no licence that permits self hosting. Anything advertised online as a downloadable "Claude model" is either a different model with a misleading name or a wrapper that calls the API. If it needs an API key, it is not local.

What is the closest open model to Claude?

There is no exact match, and the leaders change every few months. The open weight families worth testing are Llama, Qwen, Mistral, Gemma, and DeepSeek. On summarising, classification, and simple code edits a good open model at 8 to 14 billion parameters is genuinely useful. On long multi step reasoning and agentic tool use the gap to a hosted frontier model is still large. Test on your own prompts rather than trusting a leaderboard.

Is LiteLLM a self-hosted OpenRouter?

Functionally yes, for the routing and key management part. LiteLLM runs on your server, presents one OpenAI compatible endpoint, and proxies to Anthropic, Ollama, and most other providers. You get per key spend caps, model routing, and one place to read logs. What it does not give you is local inference: requests to Claude still travel to Anthropic.

Does running Claude Code on my own server keep my code private?

No. Claude Code sends the file contents it reads to the Anthropic API, wherever the process happens to be running. What a VPS gives you is isolation of the agent, not privacy of the content. Give it a dedicated unprivileged user, keep it away from credentials and unrelated repositories, and treat everything it can read as content that leaves the box.