Cut your Claude Code bill with houtini-lm, and get a second opinion

We built houtini-lm because I knew quite early on that people were going to start thinking about how many tokens (the units a model reads, writes and bills text in) they use through Claude, and what that costs, particularly as the models get more complex and more expensive per token. And we're using very, very powerful frontier models to do what I refer to as grunt tasks. Those are the bounded, routine jobs that don't need the best model in the world.

But people will want to keep using Claude Code, and that's fine, because Claude can be the orchestrator. It scopes the work, decides where each piece goes and checks what comes back, while the work itself shifts to a local model or a competing frontier model. That's what houtini-lm is. It's an MCP server. An MCP server is a small program that gives Claude Code extra tools, and houtini-lm's tools hand work to other models.

It isn't just about cost, although cost is a thing. It's about capability, it's about that second opinion, and it's about the local model on your own workstation.

Cost is a thing

I worked out my average Claude Code day from the token counts in my session logs from 25 August to 24 September 2026. I used Claude Code on every one of those 31 days, mostly on Opus 4.8 and Fable 5.x, with Opus 5.5 for the last two days. Priced at Claude Opus 5.5's list prices on 24 September, an average active day comes to about $139. I pay by subscription as well as on the API, so that's the work priced at list, not my bill.

Output is only $19.69 of it. The biggest line is cache reads at $78.80, which is the conversation context Claude re-reads on every turn - about 394 million tokens on an average day. Cache writes add $40.38.

My average Claude Code day from 25 August to 24 September 2026, priced at Claude Opus 5.5 list prices on 24 September 2026.

Priced at other models' rates, that same day's output of about 984,000 tokens would cost $1.18 on DeepSeek V4.1 Flash at peak, $0.49 on GPT-6 Luna, and nothing on a local model. GPT-6 Astra would be $49.21, two and a half times what Opus would cost.

The same output at each model's list price per million output tokens, 24 September 2026.

My view going in was that it isn't about token use directly, it's about cost per token. So we gave Claude and DeepSeek the same grunt task, a Python script using only the standard library that runs six checks on an article draft before publishing. Both passed all six. Opus 5.5 wrote 132 lines in 48 seconds, and DeepSeek V4.1 Flash, through houtini-lm, wrote 267 lines in 35. Per output token, DeepSeek Flash is about 17 times cheaper than Opus at its peak price. On the job it spent 9,149 output tokens, and 6,951 of those were hidden reasoning (the thinking a model does before it answers, which you pay for but which isn't part of the answer). That cut the saving to about 2.4 times at peak, or about 4.7 times off-peak, when DeepSeek halves its prices. So cost per token is the start of it, and how long a model thinks is the rest.

One job, one run each, priced at list. DeepSeek's peak hours are 01:00-04:00 and 06:00-10:00 UTC on weekdays.

So there are two things you can do about it: hand off the output-heavy grunt work, and keep bulky material out of Claude's context. houtini-lm's code_task_files tool does that by reading the files itself, so they never enter Claude's conversation, though Claude still spends some tokens briefing the job and reading the answer. On the API that saving is money; on a subscription it's headroom before the usage limit, which resets on a rolling five-hour window with weekly caps.

A second opinion makes the work better

All the models are so powerful now that you might find having more than one of them on a project improves its quality much faster. That's the second opinion idea. I like to be able to offload to DeepSeek for a second opinion, as well as for cheaper work.

The best example I've got is the 3.3.0 release of houtini-lm itself. Before it went out, we sent the diff, about 14,000 tokens of it, to GPT-6 Astra through houtini-lm and asked it to review the changes. It found three real bugs. All three were fixed before the release shipped.

Another model, called through houtini-lm, had already drafted two of the three new test files in that release, so more than one model had worked on it. It doesn't have to be the more expensive model, either. DeepSeek would read the same diff for a fraction of the price, and a local model for nothing. The point is that a different model is looking at the work, not the one that wrote it.

Bringing in a frontier model for its skill

Sometimes it isn't about expense, it's about capability. Every so often you want to bring in a frontier model that you know has a particular skill.

We used GPT-6 Astra very recently to help with the design work on houtini.com. I find Claude's okay at orchestrating design, but less okay at actually making the design changes itself. So Claude orchestrated the job and Astra made the design changes. Astra is more expensive per token than Opus, about 2.5 times more on output. That's the point. You pay for it only on the few tasks that need its skill.

The same idea works for images and video, just through a different MCP server. houtini-lm filters image and speech models out, so those come through our Gemini MCP instead. It puts Nano Banana Pro and Nano Banana 2 inside Claude for generating and editing images, with the text in them spelled correctly, and Veo 3.1 for video with synchronised audio. There's also Gemini 3.1 Pro for chat and deep research, grounded in Google Search.

The local model on your workstation

My view is that as developer workstations get more powerful, it's altogether probable that they'll run a local LLM, on something like an RTX PRO 6000 Blackwell. A local model is one that runs on your own hardware rather than someone else's API. Mine is a pair of 4090Ds. They're Chinese-market 4090s, modded to 48GB each, which gives me 96GB of VRAM, and they run vLLM (the settings I use are in my vLLM write-up). All of my local work goes there.

That machine takes the tasks that would be considered a little below a frontier model like Claude. For example, I have a great big index of the entire history of all the emails I've ever received. I use it as a knowledge base. It's periodically downloaded and re-indexed by my local LLM, like a RAG database, and I query it through the local LLM as well. RAG stands for retrieval-augmented generation, which means the model looks up the relevant pieces of a large collection first and then answers from what it found.

Local is free per token and it's private. The cost is the hardware and the power, which I haven't put a number on. Two RTX PRO 6000 cards would be awesome, and would let the local tier run much bigger models. That's a wish for now.

What houtini-lm does

houtini-lm talks to any endpoint that speaks the OpenAI API format. That covers a local model in LM Studio, Ollama, vLLM, SGLang or llama.cpp, a LiteLLM router, and cloud providers including OpenAI, OpenRouter, DeepSeek, Groq and Cerebras. A LiteLLM router is a single endpoint that sits in front of several models and gives each of them a short alias.

It gives Claude Code eight tools, and these are the five you'll use most. chat sends a task and brings back an answer. code_task does the same with a prompt tuned for code. code_task_files is the one that saves the most context, because houtini-lm reads the files itself and the source never enters Claude's conversation. discover reports the endpoint's health, the active model, its context window and its measured speed. stats shows the offload totals and how each model has been performing.

The top of houtini-lm's README on GitHub, at 3.3.2 when I took it.

Every call can carry a model parameter, which pins that call to one model. Leave it out and houtini-lm's routing picks one for you. So Claude can send a boilerplate job to DeepSeek Flash, a review to Astra and a bulk summarising job to the local Qwen3.6-27B, all in the same session.

By default it looks for LM Studio on localhost, port 1234. For anything else, you set an endpoint URL and an API key when you install it. It needs Node 22.5 or newer.

claude mcp add houtini-lm -- npx -y @houtini/lm

That one line is for LM Studio on the same machine. For a cloud API such as DeepSeek, add the endpoint and your key:

claude mcp add houtini-lm \
  -e HOUTINI_LM_ENDPOINT_URL=https://api.deepseek.com \
  -e HOUTINI_LM_API_KEY=your-key-here \
  -e HOUTINI_LM_SERIALISE=0 \
  -- npx -y @houtini/lm

What's changed since March

Per-task model routing arrived in 2.7, back in March, and router support landed in 3.3.0 on 23 September. houtini-lm now reads the router's model information and resolves each alias to the real model behind it, so an alias like "local" comes back as qwen3.6-27b with its real context window and output cap. It also filters out the entries that aren't chat models, 128 of the 239 on my router.

There are model profiles for DeepSeek, Gemma, OpenAI's GPT-5 and GPT-6, and Kimi. houtini-lm now captures a thinking model's hidden reasoning, so a reply that's all reasoning doesn't come back blank, and there's a switch to turn thinking on, off, or leave it on auto. On vLLM, when a call overflows the context, houtini-lm reads the real limit from the error and retries once. Output budgets are now sized for the model the call goes to. Stats moved to SQLite, and a cross-process lock stops two Claude sessions hitting one local GPU at the same time.

And 3.3.3 went out on 24 September with a fix we found while writing this page. Answers were going missing in Claude Code whenever houtini-lm also returned structured metadata, though the delegate's tokens were still counted. The metadata is now opt-in (HOUTINI_LM_STRUCTURED).

Getting Claude to delegate

Installing houtini-lm is the easy bit. Claude doesn't delegate on its own. A reminder at the start of a session doesn't survive to the middle of a task, so the habit needs a trigger, something that asks at the moment Claude is about to do the work itself.

My own setup uses two triggers, a skill and a hook. A skill is a file of instructions Claude Code loads when a task matches it. Mine lists the models I use and what each one is for, the rules for calling them, and the pipeline: Claude scopes, DeepSeek builds, the local model bug-checks, and Claude fixes and assembles. The second is a hook, a small script Claude Code runs automatically at a set point. Mine holds the first write of any substantial new file and asks whether the job should go to another model before Claude writes it itself.

You can copy the pattern. The public version of the guidance, what to hand off and how to brief it, is in houtini-lm's delegation manual.

What we've got, and what's next

So, where are we? houtini-lm is at 3.3.3, on npm and in the MCP registry, and it talks to local models, cheap cloud models and expensive capable ones. At DeepSeek Flash's price, my average day's output would cost about a dollar, as long as the model doesn't spend it all thinking. The context Claude re-reads each turn is still the biggest cost, and code_task_files keeps the files out of it.

What's next, for me, is more local capability, because a single AI model working in a single AI assistant is nothing like as powerful as the choice of multiple AI models working in your AI assistant.

Install houtini-lm, point it at one cheap endpoint or a local model, and hand off one grunt task. Then, on the next piece of work, ask a second model what it thinks. If you're not on Claude Code yet, there's a free week of Claude Code to try it with.