I build a Claude Code alternative without the cloud out of the terminal agent Pi (pi.dev), running against a local Qwen3.8-27B on my Nvidia DGX Spark. Model inference happens entirely on the machine itself, with no call to a vendor API. Whatever else such an agent touches, a web search, an MCP adapter, an update check, can absolutely reach the internet, and you have to switch that off or block it separately. For clients who can't use the cloud for legal or contractual reasons, this has become more than an experiment for me, even though it doesn't replace Claude Code in every respect.
I run my own AI workforce of eight AI employees on Claude, so I know the cloud side from daily production use. The Pi setup next to it is my test bed for the clients who can't use that cloud side at all. Everything I write about local AI and Claude is collected on the AI page.
This is where things stand for me right now, not the end of the story: what Pi with a local model can do, where you need to be careful with this setup, and who it's actually worth the effort for.
What a Claude Code alternative actually has to deliver
Claude Code works as an agent in the terminal: it reads files in a project, proposes changes, runs commands, and holds context across several steps of a task. A real alternative to it needs to manage at least three things, regardless of which model sits behind it: work with a project's file system, run commands, and not lose the thread across several rounds.
Those are exactly the three points I measure Pi with a local model against, not whether it looks the same, but whether the same kind of work gets done.
Local candidates besides Pi
Pi is my choice, but it's not the only open-source option for a cloud-free terminal coding agent. Directories of Claude Code alternatives regularly list names like OpenCode, Aider, Cline, and OpenHands alongside it, all standalone terminal or editor agents that can in principle also be pointed at a locally running model. I don't have my own review of the license details or feature scope of each individual tool, so I mention them here only as names you'll run into during your own research, not as a vetted recommendation.
What tipped it for Pi was the lean system prompt. One English-language tech site calls Pi a "minimal terminal harness" with a system prompt of roughly 200 tokens, and of the terminal agents I've tried myself, Pi's is indeed the smallest. For a local model that's an advantage: the fewer instructions sit in the context up front, the more room and attention are left for the actual task.
My setup: Pi against Qwen3.8 on the DGX Spark
Concretely, my setup looks like this: on the DGX Spark with its GB10 chip and 128 GB of unified memory, roughly 119 GB of it usable, Qwen3.8-27B runs as an NVFP4 checkpoint under SGLang, exposing an OpenAI- and Anthropic-compatible API. Pi talks to exactly that interface, so I don't need any special adaptation in the agent itself, just a different endpoint than with Claude Code.
The server runs as a systemd user unit with linger enabled, because I don't have passwordless sudo on the machine. The most important operating rule: --mem-fraction-static stays at 0.50 at most, or the whole host can freeze. The remaining pitfalls, from start-up time through the internet connection to Docker's storage cap, I've collected in Qwen 3.8 Locally: DGX Spark Experience.
What Pi can do, and where to be careful
The tooling I can confirm from my own use: Pi reads, writes, and edits files, runs commands, and searches through a project, exactly the building blocks Claude Code works with too. It picks up AGENTS.md and CLAUDE.md from the project, has skills, sessions, and subagents, offers a plan mode and a todo list, connects to further tools through MCP adapters, and can search the web. You switch models with a dedicated command, and the thinking level is adjustable. So "minimal" doesn't mean Pi is missing the pieces that make a coding agent.
One difference is worth knowing before you turn Pi loose on a real project: it has no permission system. Pi doesn't ask before it runs a command or overwrites a file, it just does it. Claude Code asks at those points, and on client work that prompt is exactly what I want. So if you work with Pi, stay in a directory under version control and don't hand the agent an account with more rights than the job needs. That is my own conclusion from the missing permission system, not a rule from the project; what Pi ships with and what it does not is documented at pi.dev.
What I can't offer is numbers for the comparison with Claude Code. My assessment so far rests on doing the same daily work with both tools, not on a properly set up benchmark, and until that changes I'm not going to sell it as a measurement.
Where the local setup hits its limits
The same English-language source that describes Pi as a minimal terminal agent also says openly that Claude Code stays ahead on multi-file refactorings, regardless of which local model you put up against it. That matches my own experience: the more files a change touches at once, and the longer an agent run takes, the more likely I am to see rework with Pi against Qwen3.8, while Claude Code holds the overview longer.
One side note from the same source stood out to me too: Anthropic reportedly locked third-party harnesses out of Claude Pro access on April 4, 2026. So anyone running an alternative terminal agent like Pi can't simply piggyback on an existing Claude subscription, the local model has to carry the work on its own, with no detour through Claude in the background. That doesn't change anything for my setup, since I run Pi against my own local model anyway, but it does show that "Claude Code alternative" needs to be meant literally here, not as a workaround to reach the same quota through the back door.
Who this is worth it for: clients without cloud access
The use case I maintain this setup for is clearly scoped: clients where code or data can't leave their own network for legal, contractual, or simply trust reasons, or where there's no reliable internet connection at the place of work. In those cases, a cloud solution, however good it is, simply isn't an option, and a local setup like Pi against Qwen3.8 becomes the only realistic answer.
For every other case, where cloud is fundamentally allowed and it's purely about task quality, I wouldn't currently recommend Pi as a substitute, but Claude Code, which is what my own workforce runs on productively. I've written up the direct comparison of both paths on the same kinds of tasks in Qwen vs Claude: Local Versus Cloud.
Frequently asked questions
Is there a free Claude Code alternative?
Pi itself is a terminal agent that I run against a self-hosted model, so I don't incur a running cost per request, but I do carry the cost of my own hardware and electricity. I can't responsibly give you a blanket statement on whether that ends up cheaper or more expensive overall than a Claude subscription without concrete usage numbers.
Can I use Claude Code for free by running Pi against a local model instead?
No, those are two separate paths. According to an English-language source, Anthropic locked third-party harnesses out of Claude Pro access on April 4, 2026, so an alternative agent like Pi can't draw on an existing Claude subscription. If you want to work locally, you need your own local model behind it.
Which model fits Pi as a coding agent?
For me, Qwen3.8-27B runs under SGLang, with tool calling and a large context window that matters for agent tasks. Whether a different model suits you better depends on your hardware and the kind of tasks you run, so I can only offer my own combination as a tested starting point.
How do I install an AI agent locally?
In my setup, a local model server runs first, in my case SGLang exposing an OpenAI- and Anthropic-compatible API, and the terminal agent Pi then points at that exact endpoint instead of a cloud service. The exact steps depend heavily on your own hardware, so I'm describing the setup here rather than a step-by-step install for every environment.
Is Pi with Qwen 3.8 a full substitute for Claude Code?
For tasks with a hard cloud ban or no internet access, yes, because it's the only option there. For everything else, I still see an advantage for Claude Code on multi-file refactorings and long agent runs, which is also why my own workforce runs there.
How to weigh this for yourself
If cloud is generally an option for you or your clients, I'd read Claude Code: A Guide for Beginners first, before putting in the effort for your own local setup. I describe my Qwen3.8 setup on the DGX Spark in technical detail in Qwen 3.8 Locally: DGX Spark Experience, and the direct comparison of both paths on the same tasks in Qwen vs Claude: Local Versus Cloud.
Official background on the tools in this post is available directly at Pi, in the SGLang project on GitHub, and at Anthropic.
