@houtini/lm Houtini LM - Save Tokens by Offloading Tasks from Claude Code to Your Local LLM Server (LM Studio / Ollama), Openrouter or a Cloud API
Quick Navigation
How it works | Quick start | What gets offloaded | Tools | Performance tracking | Structured JSON output | Model routing | Self-test (shakedown) | Configuration | Compatible endpoints | Developer guide
I built this because I kept leaving Claude Code running overnight on big refactors and the token bill was painful. A huge chunk of that spend goes on bounded tasks any decent model handles fine - generating boilerplate, code review, commit messages, format conversion. Stuff that doesn't need Claude's reasoning or tool access.
Houtini LM connects Claude Code to a local LLM on your network - or any OpenAI-compatible API (LM Studio, Ollama, vLLM, DeepSeek, Groq, Cerebras, and OpenRouter's 300+ models through one endpoint). Claude keeps doing the hard work - architecture, planning, multi-file changes - and offloads the grunt work to whatever cheaper model you've got running. No Claude quota burn. No rate limits. Private if local, cheap if cloud. The trade is wall-clock time: local inference is typically 3-30× slower than frontier models, so delegation wins on bounded, self-contained tasks rather than everything.
I wrote a full walkthrough of why I built this and how I use it day to day.
The manual
This README is the overview. The depth lives in focused pages:
| Page | What's in it |
|---|---|
| Getting started | Local models from zero: LM Studio or Docker, what small models are good at, which fit your VRAM |
| The tools, in depth | All eight tools: the parameters that matter, reading the footer, the max_tokens floor |
| The craft of delegation | What to hand off and how to brief it - the verbatim-echo pattern, micro-chunking, reasoning-model budgets |
| Troubleshooting | Symptom → cause → fix: empty responses, timeouts, context-length 400s, queuing |
| LM Studio setup · Ollama setup · vLLM setup | Backend guides, each with the traps that cause silent failures |
| vLLM backend notes | The deeper operational record: router topology, thinking toggles, token budgets |
| CLI mode | Running houtini-lm as a command, not just an MCP server |
| Shakedown test | The canonical end-to-end check - npm run shakedown, or paste the prompt into Claude and watch all eight tools run |
| Developer guide | Architecture, contributing, release process |
How it works
Claude Code (orchestrator)
|
|-- Complex reasoning, planning, architecture --> Claude API (your tokens)
|
+-- Bounded grunt work --> houtini-lm --HTTP/SSE--> Your local LLM (free)
. Boilerplate & test stubs Qwen, Llama, Nemotron, GLM...
. Code review & explanations LM Studio, Ollama, vLLM, llama.cpp
. Commit messages & docs DeepSeek, Groq, Cerebras (cloud)
. Format conversion
. Mock data & type definitions
. Embeddings for RAG pipelines
Claude's the architect. Your local model's the drafter. Claude QAs everything.
Quick start
New to local models? See docs/GETTING-STARTED.md — installing LM Studio or a Docker endpoint, getting an OpenAI-compatible URL for houtini, what the smaller models are good at, and which models fit on 16/32/64/96/128 GB of VRAM.
Setting up a specific backend? Step-by-step guides, each with the traps that cause silent failures: LM Studio (easiest, desktop) · Ollama (two commands, CLI) · vLLM (throughput, tool-calling, long context).
Claude Code
claude mcp add houtini-lm -- npx -y @houtini/lm
That's it. If LM Studio's running on localhost:1234 (the default), Claude can start delegating straight away.
LLM on a different machine
I've got a GPU box on my local network running Qwen 3 Coder Next in LM Studio. If you've got a similar setup, point the URL at it:
claude mcp add houtini-lm -e HOUTINI_LM_ENDPOINT_URL=http://192.168.1.50:1234 -- npx -y @houtini/lm
Cloud APIs
Works with anything speaking the OpenAI format. DeepSeek at twenty-eight cents per million tokens, Groq for speed, Cerebras if you want three thousand tokens per second - whatever you fancy:
claude mcp add houtini-lm \
-e HOUTINI_LM_ENDPOINT_URL=https://api.deepseek.com \
-e HOUTINI_LM_API_KEY=your-key-here \
-- npx -y @houtini/lm
OpenRouter
OpenRouter gives you 300+ models through one endpoint. Auto-detected from the URL — attribution headers, reasoning.exclude, and retry-with-backoff all kick in automatically:
claude mcp add houtini-lm \
-e HOUTINI_LM_ENDPOINT_URL=https://openrouter.ai/api \
-e HOUTINI_LM_API_KEY=sk-or-v1-... \
-e HOUTINI_LM_MODEL=nvidia/nemotron-3-nano-30b-a3b:free \
-- npx -y @houtini/lm
Claude Desktop
Drop this into your claude_desktop_config.json:
{
"mcpServers": {
"houtini-lm": {
"command": "npx",
"args": ["-y", "@houtini/lm"],
"env": {
"HOUTINI_LM_ENDPOINT_URL": "http://localhost:1234"
}
}
}
}
Model discovery
This is where things get interesting. At startup, houtini-lm queries your LLM server for every model available - loaded and downloaded - then looks each one up on HuggingFace's free API to pull metadata: architecture, licence, download count, pipeline type. All of that gets cached in a local SQLite database (~/.houtini-lm/model-cache.db) so subsequent startups are instant.
The result is that houtini-lm actually knows what your models are good at. Not just the name - the capabilities, the strengths, what tasks to send where. If you've got Nemotron loaded but a Qwen Coder sitting idle, it'll flag that. If someone on a completely different setup loads a Mistral model houtini-lm has never seen before, the HuggingFace lookup auto-generates a profile for it.
Run list_models and you get the full picture:
Loaded models (ready to use):
nvidia/nemotron-3-nano
type: llm, arch: nemotron_h_moe, quant: Q4_K_M, format: gguf
context: 200,082 (max 1,048,576), by: nvidia
Capabilities: tool_use
NVIDIA Nemotron: compact reasoning model optimised for step-by-step logic
Best for: analysis tasks, code bug-finding, math/science questions
HuggingFace: text-generation, 1.7M downloads, MIT licence
Available models (downloaded, not loaded):
qwen3-coder-30b-a3b-instruct
type: llm, arch: qwen3moe, quant: BF16, context: 262,144
Qwen3 Coder: code-specialised model with agentic capabilities
Best for: code generation, code review, test stubs, refactoring
HuggingFace: text-generation, 12.9K downloads, Apache-2.0
For models we know well - Qwen, Nemotron, Granite, LLaMA, GLM, GPT-OSS - there's a curated profile built in with specific strengths and weaknesses. For everything else, the HuggingFace lookup fills the gaps. Cache refreshes every 7 days. Zero friction - the cache uses node:sqlite (Node's built-in SQLite, so no third-party native dependency and no build tools) in WAL mode, which lets several houtini-lm processes share one cache safely. Requires Node ≥ 22.5.
What gets offloaded
Delegate to the local model - bounded, well-defined tasks:
| Task | Why it works locally |
|---|---|
| Generate test stubs | Clear input (source), clear output (tests) |
| Explain a function | Summarisation doesn't need tool access |
| Draft commit messages | Diff in, message out |
| Code review | Paste full source, ask for bugs |
| Convert formats | JSON to YAML, snake_case to camelCase |
| Generate mock data | Schema in, data out |
| Write type definitions | Source in, types out |
| Structured JSON output | Grammar-constrained, guaranteed valid |
| Text embeddings | Semantic search, RAG pipelines |
| Brainstorm approaches | Doesn't commit to anything |
Keep on Claude - anything that needs reasoning, tool access, or multi-step orchestration:
- Architectural decisions
- Reading/writing files
- Running tests and interpreting results
- Multi-file refactoring plans
- Anything that needs to call other tools
The tool descriptions are written to nudge Claude into planning delegation at the start of large tasks, not just using it when it happens to think of it.
Performance tracking
Every response includes a footer with real performance data — computed from the SSE stream, not from any proprietary API:
---
Model: