Probe0 vs LM Studio
LM Studio is the thing that runs the model. Probe0 is the thing that decides which model a request should go to, and what it costs you when the answer comes from a cloud provider instead. Most people who compare the two end up running both.
A desktop app and local API server for downloading and running open-weight models on your own machine, built on llama.cpp and Apple MLX.
| Feature | Probe0 | LM Studio | Edge |
|---|---|---|---|
| What it is | Local proxy in front of your coding agents | Local runtime and model server | Even |
| Runs open-weight models on your machine | No, it routes to Ollama or LM Studio | Yes, GGUF via llama.cpp and MLX on Apple Silicon | Competitor |
| Setup to cover every coding agent CLI | One proxy, one cert, once. Claude Code, Codex, Cursor | Point each tool at the endpoint yourself | Probe0 |
| Routing between local and cloud | Local first, weak answers auto-retried on the cloud | No provider routing in the gateway sense | Probe0 |
| Response cache across requests | Exact cache on local disk, hits never hit the network | Engine-level KV prefix reuse only, no response cache | Probe0 |
| Cache safety inside agent tool loops | Semantic cache refuses to match anything carrying tool calls | No semantic cache to guard | Probe0 |
| Spend cap on cloud calls | Hard cap per run and per day, warns then pauses | None, and local inference has no per-token bill | Probe0 |
| Which process spent the money | Per-call ledger: model, tokens, real cost, latency, process | Server logs and lms log streaming | Probe0 |
| Savings you can check | Each module toggles alone and reports what it saved | No cost surface, so nothing to report | Probe0 |
LM Studio solves the problem I have no answer to at all: you type a model name into a search box, it shows you the quantizations, one click later the weights are on disk, and llama.cpp or MLX serves them with GPU offload and idle eviction handled for you. Probe0 sits one layer up and treats that server as a backend, which is the layer where a developer running coding agents actually loses money. One local proxy and one certificate, installed once, cover Claude Code, Codex and Cursor with no per-tool config. Local Routing sends eligible work to a model you already have loaded in LM Studio or Ollama and quietly retries a weak answer on the cloud, which is what makes local routing survive real agent traffic instead of a demo. There is no Probe0 server anywhere; nothing about your traffic leaves the machine unless the request was already headed to a cloud provider.
What LM Studio does not do is anything about the money, and that is the shape of the product rather than a flaw in it. Local inference has no per-token bill, so there is nothing to cap, nothing to attribute, nothing to route on price. The moment a cloud provider enters the picture, and for anyone using an AI coding agent it already has, those gaps start to matter: no cross-provider fallback, no cost-tiered routing, no response cache or cross-request dedup above the engine, no usage dashboard or per-key attribution, and the optional API token auth added in 0.4.0 is off by default. Even the caching that does exist lives in the engines and has regressed quietly before. LM Studio bug #1563 has llama.cpp silently disabling KV reuse and refilling the whole prefix each request, and mlx-lm #980 covers broken prefix reuse on hybrid and sliding-window architectures. You find out from your latency, not from a number on a screen.
The pieces that close that gap are the reason I would put Probe0 in front. Model Tiering tries the cheap model first and escalates only when the answer needs it. Exact Cache lives on local disk and a hit never touches the network. Semantic Cache uses a local vector index with a strict similarity floor and refuses to match anything carrying tool calls, because a wrong hit inside a tool loop corrupts the run. Request Coalescing collapses simultaneous identical calls into one upstream request. Spend Guard sets a hard cap per run and per day: it warns, then pauses, which is the difference between a budget and a notification. Recording keeps a per-call ledger down to which process made the call, so you can see that the runaway spend came from one agent and not from you, and because it knows real usage it will tell you when you are paying for a plan tier above what you use. Every module switches off on its own and reports what it saved, so each one is judged on its own numbers. Sign-in is Google or GitHub, no password.
The verdict
For a developer on a Mac running coding agents against cloud models, Probe0 is the one I would install, and I would keep LM Studio underneath it as the local backend. The single case where LM Studio alone is the right answer is when you do not have a local model running yet, or you want the chat UI, local RAG and a Windows or Linux box. Once a model is loaded and the bill is still arriving, the missing layer is a cap that pauses, a cache that never reaches the network, and a ledger that names the process. That is Probe0.
Questions
- Is Probe0 an LM Studio alternative?
- Not really. LM Studio runs models and Probe0 is an LLM proxy that routes to whatever is running, including LM Studio. They stack rather than replace each other. The only overlap is that both keep work on your machine.
- Can Probe0 route my AI coding agent to a model running in LM Studio?
- Yes. Local Routing sends eligible requests to a model already loaded in LM Studio or Ollama, and if the answer comes back weak it retries on the cloud automatically. That auto-retry is what makes local LLM routing safe to leave on during a real coding session.
- Does LM Studio have spend limits or cost tracking?
- No. It has server logs and lms log streaming, but no usage dashboard, no per-key attribution and no budgets, which makes sense because local inference has no per-token bill. LLM cost control only becomes a question once cloud providers are in the mix, which is where Probe0 comes in.
- Does LM Studio cache responses between requests?
- Only the KV prefix reuse that llama.cpp and mlx-lm provide, and that has broken silently for specific model architectures in past releases. There is no response cache, no semantic cache and no dedup of simultaneous identical calls above the engine.