Houtini LM

Houtini LM (@houtini/lm) - Transfira trabalho do Claude Code para um LLM local, OpenAI GPT-5/6, um roteador ou um modelo de nuvem mais barato

Houtini LM é um servidor MCP que permite ao Claude (ou a qualquer cliente MCP) entregar tarefas delimitadas a outro modelo - um LLM local na sua GPU, os modelos GPT mais recentes da OpenAI, um roteador LiteLLM, OpenRouter ou uma API de nuvem barata - enquanto você continua trabalhando na plataforma de IA que já gosta. Isso reduz sua conta de tokens e oferece um segundo modelo para revisar seu código sempre que quiser.

Navegação rápida

O que há de novo | Por que usar | Instalação | Como lida com diferentes modelos | O que delegar | Ferramentas | Lendo o rodapé | Configuração | Endpoints | O manual

Construí isso porque vivia deixando o Claude Code rodando a noite toda em grandes refatorações e a conta de tokens era dolorosa. Uma enorme parte desse gasto ia para tarefas delimitadas que qualquer modelo decente resolve bem - gerar boilerplate, revisão de código, mensagens de commit, conversão de formatos, o tipo de trabalho que não precisa do raciocínio do Claude nem do acesso a ferramentas dele.

Então o Claude continua sendo o arquiteto, fazendo o planejamento, as mudanças em vários arquivos e os julgamentos, e o houtini-lm passa o rascunho para o modelo que você tiver rodando. Pode ser um Qwen numa GPU embaixo da sua mesa, GPT-5 ou GPT-6 direto da OpenAI, um modelo atrás de um roteador LiteLLM, um dos 300+ modelos do OpenRouter ou DeepSeek a centavos por milhão de tokens. O Claude faz o controle de qualidade de tudo o que volta.

Escrevi um passo a passo completo de por que construí isso e como uso no dia a dia se você quiser a história mais longa.

O que há de novo na versão 3.3

O houtini-lm agora fala com muito mais do que uma GPU local. Aponte-o diretamente para a OpenAI e GPT-5, GPT-6 e os modelos de raciocínio da série o funcionam sem nenhum roteador no meio. Eles rejeitam parâmetros que todo modelo aberto aceita (max_tokens, temperature), então o houtini-lm envia max_completion_tokens apenas, aprende o limite de saída de um modelo a partir do próprio erro quando o endpoint não o informa, e deixa os modelos de imagem, fala e moderação fora da lista. Aponte-o para um roteador LiteLLM e ele lê qual modelo real está por trás de cada alias, junto com a verdadeira janela de contexto e o limite de saída desse modelo, para que uma frota mista de modelos locais e hospedados seja dimensionada e perfilada corretamente. O pensamento agora é decisão sua (auto, off ou on), há um guia do Docker construído a partir de uma implantação funcional, e o manual tem uma página por tarefa. O changelog tem os detalhes.

Por que usar o houtini-lm?

O essencial antes de irmos a fundo: você mantém sua plataforma de IA favorita e para de pagar preço de modelo de fronteira por trabalho que não precisa de um modelo de fronteira.

A vantagem óbvia é o custo. Quando o Claude delega uma revisão com code_task_files, os arquivos de origem são lidos pelo processo do houtini-lm e enviados direto para o outro modelo, então nunca entram na janela de contexto do Claude. O Claude envia uma chamada de ferramenta curta e lê uma resposta curta. Fiz benchmark disso em arquivos TypeScript reais:

Tarefa	Claude lê diretamente	Delegado	Economia
Revisão de código (1.352 linhas)	14.466 tokens	769 tokens	95%
Revisão de arquitetura (2.022 linhas)	20.014 tokens	983 tokens	95%
Revisão de repositório externo (581 linhas)	5.344 tokens	741 tokens	86%
Explicação de código (833 linhas)	8.678 tokens	744 tokens	91%

Isso dá uma média de 93,3% de economia na sessão. Para ser justo, tarefas pequenas como uma pergunta de uma linha ou uma mensagem de commit não economizam muito, porque a sobrecarga da chamada de ferramenta (cerca de 250 tokens) tem quase o mesmo tamanho da resposta. Qualquer coisa que envolva ler arquivos, que é a maior parte de uma sessão real de codificação, se paga imediatamente. Você pode rodar o mesmo benchmark na sua própria configuração com LM_STUDIO_URL=http://your-server:1234 node scripts/benchmark.mjs.

A vantagem menos óbvia é uma segunda opinião. Um modelo diferente lê seu código com pontos cegos diferentes, e custa quase nada pedir. Aliás, o lançamento 3.3.0 deste repositório é um bom exemplo: pedi ao Claude para apontar o houtini-lm para gpt-6-astra (através do meu roteador LiteLLM) e pedir uma revisão do diff de 14.000 tokens do próprio lançamento. Ele voltou com três bugs reais - uma sonda de roteador que armazenava em cache um 429 temporário como "não é um roteador" permanente, um limite de saída que era sobrescrito e uma condição de corrida no cache da lista de modelos - e todos os três foram corrigidos antes do lançamento. Dois dos três novos arquivos de teste foram rascunhados da mesma forma e depois revisados pelo Claude antes do commit.

A revisão de código é onde isso compensa mais, porque revisões são exatamente o trabalho delimitado, de ler muito e escrever pouco, que um modelo mais barato faz bem. A partir daí a lista continua crescendo: stubs de teste, docstrings, mensagens de commit, rascunhos de changelog, conversão de formatos, dados simulados, definições de tipo, embeddings para um pipeline de RAG, uma verificação rápida de sanidade numa regex, brainstorming de três abordagens antes de o Claude se comprometer com uma, e assim por diante.

A troca é o tempo de relógio. Inferência local é tipicamente 3 a 30 vezes mais lenta que um modelo de fronteira, então a delegação vence em tarefas delimitadas e autocontidas, não em tudo. Um modelo local mantém seu código privado e não custa nada por token; um modelo de nuvem é barato, e nenhum dos dois toca sua cota do Claude nem os limites de taxa dele.

Como funciona

Claude Code, Claude Desktop, Cursor... (orchestrator)
   |
   |-- Reasoning, planning, architecture, tool use --> your main AI platform
   |
   +-- Bounded grunt work --> houtini-lm --HTTP/SSE--> any OpenAI-compatible endpoint
       . Code review & second opinions       LM Studio, Ollama, vLLM, SGLang, llama.cpp
       . Test stubs & boilerplate            LiteLLM routers
       . Commit messages & docs              OpenRouter (300+ models)
       . Format conversion & mock data       DeepSeek, Groq, Cerebras, OpenAI...
       . Embeddings for RAG pipelines

O Claude é o arquiteto, o outro modelo é o redator, e o Claude verifica tudo o que volta.

Instalação

Você vai precisar do Node 22.5 ou mais novo e de um endpoint compatível com OpenAI: LM Studio, Ollama, vLLM, SGLang, um roteador LiteLLM ou uma chave de API de nuvem para OpenAI, DeepSeek, Groq e afins. No Claude Code, com o LM Studio rodando na mesma máquina, é um comando:

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

É isso. O LM Studio escuta em localhost:1234 por padrão, que é onde o houtini-lm procura primeiro, então o Claude pode começar a delegar imediatamente. Em qualquer outro lugar, defina a URL (e uma chave, se o endpoint precisar):

claude mcp add houtini-lm \
  -e HOUTINI_LM_ENDPOINT_URL=http://192.168.1.50:1234 \
  -e HOUTINI_LM_API_KEY=your-key-if-needed \
  -- npx -y @houtini/lm

A OpenAI funciona do mesmo jeito. Fixe o modelo que você quer, porque a OpenAI lista dezenas e todos pontuam igual no roteamento:

claude mcp add houtini-lm \
  -e HOUTINI_LM_ENDPOINT_URL=https://api.openai.com \
  -e HOUTINI_LM_API_KEY=sk-... \
  -e HOUTINI_LM_MODEL=gpt-5.2 \
  -e HOUTINI_LM_SERIALISE=0 \
  -- npx -y @houtini/lm

Instalando o houtini-lm percorre todas as rotas: uma GPU em outra máquina, OpenAI e outras APIs de nuvem, OpenRouter, um roteador LiteLLM, Claude Desktop e outros clientes MCP, além de como verificar se funcionou e como atualizar. Se preferir rodar em um contêiner, Rodando o houtini-lm no Docker cobre tanto um docker run -i simples quanto servi-lo via HTTP atrás do MCP Gateway do Docker. Novo em modelos locais? Comece com Começando, que cobre quais modelos cabem em 16, 32, 64, 96 ou 128 GB de VRAM.

Para verificar se está tudo conectado, peça ao Claude para rodar a ferramenta discover do houtini-lm. Ela informa a versão, qual endpoint foi encontrado, qual modelo está ativo e o tamanho da janela de contexto dele.

Como o houtini-lm lida com diferentes modelos

Não existem dois LLMs de código aberto iguais. Eles diferem em janela de contexto, limite de saída, template de prompt, se pensam antes de responder e quanto disso relatam, então muito do código do houtini-lm é sobre descobrir com o que está falando e se ajustar a isso. Como o houtini-lm lida com diferentes modelos tem todos os detalhes, e aqui está a versão curta.

Na inicialização, o houtini-lm pergunta ao seu servidor por todos os modelos que ele tem, carregados e baixados, e procura cada um no HuggingFace pela arquitetura, licença e template de chat, armazenando tudo em cache no SQLite para que inicializações posteriores sejam instantâneas. Para as famílias que conheço bem (Qwen, Nemotron, Granite, LLaMA, GLM, GPT-OSS, DeepSeek, Gemma, Kimi e os modelos GPT hospedados da OpenAI) há um perfil curado, e cada família recebe sua própria temperatura, restrições de saída e tratamento de blocos de pensamento, enquanto os modelos de raciocínio hospedados da OpenAI (GPT-5/6, série o) recebem apenas os parâmetros que aceitam. Rode list_models e você tem o panorama completo:

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

Os orçamentos de saída vêm do modelo para o qual cada chamada é realmente enviada. Deixe max_tokens sem definir e a chamada recebe 25% da janela de contexto desse modelo, nunca mais do que o limite de saída declarado ou o espaço restante ao lado do seu prompt, para que um modelo hospedado não receba uma solicitação que vai rejeitar. Há também um piso, porque clientes MCP costumam passar limites minúsculos como 256 que sufocam modelos de raciocínio no meio do pensamento, então qualquer coisa abaixo de 4.096 é ignorada, a menos que você defina HOUTINI_LM_MIN_TOKENS=0.

O pensamento é sua decisão, através de HOUTINI_LM_THINKING. O padrão, auto, desliga o pensamento para modelos detectados como suportando o alternador (Qwen3, Gemma 4, Nemotron, DeepSeek R1, GLM-4, gpt-oss), o que combina com o Claude fazendo o raciocínio e o outro modelo fazendo o rascunho. off força isso em todas as chamadas, o que você precisa quando um backend serve um modelo de pensamento sob um nome que a detecção não reconhece. on força o pensamento ligado, o que vale a pena para caçar bugs ou verificar um argumento, ao custo de tempo e tokens. Seja qual for sua escolha, o houtini-lm infla o orçamento de saída para modelos de pensamento e remove quaisquer blocos <think> da resposta, para que o raciocínio não deixe você com uma resposta vazia.

Com vários modelos disponíveis, o houtini-lm pontua cada um contra o tipo de tarefa e escolhe o melhor, e sugere um modelo melhor em vez de trocar um, já que carregar um modelo leva minutos. Num catálogo grande, todo modelo desconhecido pontua igual e o primeiro listado vence, então fixe um com HOUTINI_LM_MODEL, ou passe model numa chamada individual.

Aponte-o para um roteador LiteLLM e ele também lê /model/info, o que informa o modelo real por trás de cada alias (meu alias local é qwen3.6-27b) e, para modelos hospedados, a verdadeira janela de contexto e o limite de saída. Cada alias é então perfilado e dimensionado como o modelo que realmente é, os modelos de TTS, imagem e vídeo que um roteador lista às dúzias são filtrados, e erros de limite de taxa são repetidos com backoff. Chamadas são enfileiradas uma de cada vez por padrão, porque uma única GPU só consegue atender uma solicitação de qualquer forma; o OpenRouter pula a fila, e para OpenAI, um roteador ou um backend de loteamento como vLLM você pode desligar isso com HOUTINI_LM_SERIALISE=0.

O que delegar

Os melhores candidatos são delimitados e bem definidos, com entrada e saída claras:

Tarefa	Por que funciona em outro modelo
Revisão de código	Cole o código-fonte completo (ou passe os caminhos), peça por bugs
Segunda opinião sobre um plano	Não se compromete com nada, custa quase nada
Gerar stubs de teste	Código-fonte entra, testes saem
Explicar uma função	Resumir não precisa de acesso a ferramentas
Rascunhar mensagens de commit	Diff entra, mensagem sai
Converter formatos	JSON para YAML, snake_case para camelCase
Gerar dados simulados	Schema entra, dados saem
Escrever definições de tipo	Código-fonte entra, tipos saem
Saída JSON estruturada	Restrita por gramática, válida por construção
Embeddings de texto	Busca semântica, pipelines de RAG

Qualquer coisa que precise de raciocínio sobre o código-base, acesso a ferramentas ou orquestração em várias etapas fica no Claude: decisões arquiteturais, ler e escrever arquivos, rodar testes e interpretar os resultados, planos de refatoração em vários arquivos e qualquer coisa que tenha que chamar outras ferramentas. As descrições das ferramentas são escritas para incentivar o Claude a planejar a delegação no início de uma tarefa grande, em vez de usá-la apenas quando ele se lembrar.

As ferramentas

São oito no total. A referência completa dos parâmetros está em As ferramentas, em detalhe.

Ferramenta	Para que serve
chat	O cavalo de batalha. Envie uma tarefa, receba uma resposta.
custom_prompt	Sistema, contexto e instrução mantidos separados, o que consistentemente supera colocar tudo em uma única mensagem em modelos locais. Testei isso direito em um fim de semana com o mesmo lote de tarefas de revisão executado das duas formas, e a versão em três partes venceu todas as rodadas.
code_task	Análise de código com um prompt de sistema ajustado para código e temperatura por família.
code_task_files	Como code_task, mas o houtini-lm lê os arquivos do disco por conta própria, então a fonte nunca passa pelo contexto do Claude. Arquivos ilegíveis são reportados inline em vez de derrubarem a chamada, e um estimador de pré-verificação recusa entradas que os dados medidos indicam que dariam timeout.
embed	Embeddings de texto via /v1/embeddings (Nomic Embed é uma escolha sólida).
discover	Verificação de saúde: endpoint, modelo ativo, janela de contexto, limite de saída e velocidade medida assim que houver uma chamada real para medir.
list_models	Tudo no servidor, carregado e baixado, com perfis.
stats	Totais de offload por sessão e por tempo de vida e desempenho por modelo, sem o catálogo de modelos.

As ferramentas de inferência (chat, custom_prompt, code_task, code_task_files) todas aceitam um model opcional para fixar a chamada, max_tokens, e controles de amostragem (temperature, seed, stop, top_p, top_k, repeat_penalty, frequency_penalty, presence_penalty). chat e custom_prompt também aceitam um json_schema, que força a resposta a estar em conformidade com um JSON Schema; no LM Studio isso é amostragem baseada em gramática, então não há esperança de que o modelo se lembre de fechar os colchetes:

{
  "json_schema": {
    "name": "code_review",
    "schema": {
      "type": "object",
      "properties": {
        "issues": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "line": { "type": "number" },
              "severity": { "type": "string" },
              "description": { "type": "string" }
            },
            "required": ["line", "severity", "description"]
          }
        }
      },
      "required": ["issues"]
    }
  }
}

Se você está dirigindo o houtini-lm a partir dos seus próprios scripts em vez de pelo Claude, defina HOUTINI_LM_STRUCTURED=1 e cada resultado de inferência também carrega um bloco structuredContent (a resposta, modelo, tokens, tempo, flags de qualidade) para ler como JSON. Deixe desligado para o Claude Code, que mostra ao modelo apenas esse bloco quando presente (a página de ferramentas conta a história).

Lendo o rodapé

Toda resposta termina com um rodapé calculado a partir do próprio stream SSE:

---
Model: nvidia/nemotron-3-nano | 279→303 tokens (12 reasoning / 291 visible) | TTFT: 485ms, 58.0 tok/s, 5.2s
📊 First measured call on nvidia/nemotron-3-nano: 58.0 tok/s, 485ms to first token - use this to gauge whether to delegate longer tasks.
💰 Offloaded - this session: 4,283 tokens / 7 calls · lifetime: 147,432 tokens / 213 calls

A linha de primeira chamada aparece uma vez por modelo por sessão, e é um benchmark de uma tarefa real em vez de um aquecimento sintético. A linha 💰 atualiza a cada chamada, e conta os tokens que o outro modelo processou (seu prompt e conclusão, raciocínio incluído), que é trabalho que o Claude não fez, em vez de uma medida de tokens do Claude economizados; o benchmark acima é a medida honesta disso. Quando um modelo reporta seus tokens de raciocínio, a contagem de tokens se divide em raciocínio e visível, para que você possa ver quando um modelo pensante está queimando orçamento em raciocínio oculto.

Quando algo deu errado, uma linha de qualidade diz isso: TRUNCATED para um resultado parcial (uma conexão travada dá a você o que chegou em vez de um erro de timeout), hit-max-tokens quando o orçamento acabou, think-blocks-stripped quando o raciocínio foi removido e tokens-estimated quando o servidor não reportou uso. Saída limpa não recebe linha de qualidade alguma.

Velocidade por modelo e contagens de tokens persistem em ~/.houtini-lm/model-cache.db, então discover mostra seu tok/s medido e tempo até o primeiro token da primeira chamada de uma nova sessão, e stats dá a você os totais de tempo de vida. Esses dados são específicos da sua estação de trabalho de propósito, porque decisões de delegação devem refletir seu hardware em vez do benchmark de outra pessoa. Na prática, o Claude delega mais quanto mais longa a sessão; após cerca de 5.000 tokens offloadados, ele começa a procurar mais trabalho para empurrar.

Obtendo bons resultados

Qwen, Llama, Nemotron e GLM pontuam brilhantemente em benchmarks de codificação agora, e a lacuna entre um bom e um mau resultado é quase sempre o prompt em vez do modelo. Passei um bom tempo nisso, e a versão curta é assim. Envie código completo, porque modelos locais inventam detalhes quando a entrada é truncada, então envie a função inteira em vez de um trecho com ... no meio. Seja explícito sobre o formato de saída ("retorne um array JSON"), já que modelos menores precisam disso. Dê ao modelo uma persona específica ("desenvolvedor Rust especialista que se preocupa com segurança de memória" funciona visivelmente melhor do que "assistente útil"), declare o que não fazer além do que fazer, e para geração de código inclua os imports, tipos e assinaturas ao redor do corpo da função.

Mantenha trabalhos longos em pedaços também. A maioria dos clientes MCP define timeout de chamada de ferramenta em cerca de 60 segundos, e embora o houtini-lm envie uma notificação de progresso em cada pedaço transmitido para manter o relógio resetado, nem todo cliente ou gateway repassa essas notificações. Chamadas de aproximadamente 500-900 tokens de saída terminam confortavelmente dentro do limite. A arte da delegação vai muito mais fundo, incluindo o padrão de eco verbatim que uso para correções.

Verifique sua instalação

npm run shakedown

scripts/shakedown.mjs executa sete das oito ferramentas de ponta a ponta (tudo exceto stats) e imprime uma tabela de TTFT real, tok/s, contagens de tokens e divisão de raciocínio para cada chamada. Leva menos de um minuto em uma máquina decente:

Summary

   7/7 steps passed on LM Studio, model=nvidia/nemotron-3-nano

| Tool              | OK  | TTFT (ms) | tok/s  | Tokens in→out        | Reasoning | Notes
| chat              | ✅  |      891  |   36.9 | 48→104               |        —  | answered
| custom_prompt     | ✅  |      872  |   43.9 | 170→333              |        —  | 5 valid items
| code_task         | ✅  |      857  |   41.6 | 180→189              |        —  | tests generated
| code_task_files   | ✅  |   11028   |   39.5 | 6891→3000            |        —  | cross-referenced
| embed             | ✅  |      —    |     —  | —                    |        —  | 768-dim vector

   Tokens offloaded: 10,915 (prompt: 7,289, completion: 3,626, reasoning: 0)

Se você prefere uma revisão de qualidade em vez de números de latência, cole SHAKEDOWN.md em uma sessão do Claude com o houtini-lm anexado e o Claude dirigirá os mesmos passos e escreverá um relatório sobre a saída além da velocidade.

Configuração

A maioria das configurações precisa apenas das duas ou três primeiras destas. A lista completa, incluindo os controles de acesso a arquivos e fila, está em Configuração.

Variável	Padrão	O que faz
HOUTINI_LM_ENDPOINT_URL	http://localhost:1234	URL base da API compatível com OpenAI, sem /v1.
HOUTINI_LM_API_KEY	(nenhum)	Token Bearer para endpoints autenticados.
HOUTINI_LM_MODEL	(auto-detectado)	O modelo que as chamadas usam a menos que nomeiem um. Fixe-o em roteadores e catálogos grandes.
HOUTINI_LM_THINKING	auto	auto, off ou on - veja Pensamento: auto, desligado ou ligado.
HOUTINI_LM_SERIALISE	1	Defina como 0 para APIs em nuvem como OpenAI, roteadores na frente de modelos em nuvem e backends que processam em lote nativamente (vLLM, SGLang).
HOUTINI_LM_MIN_TOKENS	4096	Piso para max_tokens fornecido pelo chamador. Defina como 0 para honrar qualquer valor.

Endpoints compatíveis

Qualquer coisa que fale a API /v1/chat/completions compatível com OpenAI funcionará:

O quê	URL	Notas
LM Studio	http://localhost:1234	Padrão, zero configuração, metadados ricos via sua API v0. Guia de configuração
Ollama	http://localhost:11434	Modelos pensantes (qwen3, deepseek-r1) tratados via canal delta.reasoning do Ollama. Guia de configuração
vLLM	http://localhost:8000	API OpenAI nativa. Guia de configuração
SGLang	http://localhost:30000	Bom para trabalho com contexto repetido. Veja Começando
LiteLLM roteador	http://localhost:4000	Auto-detectado: aliases resolvidos, limites reais lidos, modelos não-chat filtrados, backoff 429
llama.cpp	http://localhost:8080	Modo servidor
OpenAI	https://api.openai.com	GPT-5, GPT-6 e a série o enviados apenas com os parâmetros que aceitam; modelos de imagem, fala e moderação deixados fora da lista. Fixe um modelo
OpenRouter	https://openrouter.ai/api	300+ modelos, auto-detectado, requisições paralelas permitidas
DeepSeek	https://api.deepseek.com	Muito barato por token
Groq	https://api.groq.com/openai	Rápido
Cerebras	https://api.cerebras.ai	Muito rápido
Qualquer API compatível com OpenAI	Qualquer URL	Defina a URL e a chave da API

O manual

Este README é a visão geral, e a profundidade vive nestas páginas:

Página	O que contém
Instalando o houtini-lm	Todas as rotas de instalação: local, GPU remota, nuvem, OpenRouter, LiteLLM, Claude Desktop, outros clientes e atualização
Executando o houtini-lm em Docker	docker run -i, ou servido via HTTP atrás do MCP Gateway do Docker, com as armadilhas que medimos
Como o houtini-lm lida com diferentes modelos	Descoberta, perfis, pensamento (auto, desligado ou ligado), orçamentos de saída, roteamento, roteadores LiteLLM, modelos que rejeitam parâmetros
Configuração	Cada variável de ambiente, configurações por chamada e onde o estado vive
As ferramentas, em detalhe	Todas as oito ferramentas: os parâmetros, leitura do rodapé, o piso de max_tokens
A arte da delegação	O que delegar e como instruir, o padrão de eco verbatim, micro-pedaços, orçamentos de modelos pensantes
Solução de problemas	Sintoma > causa > correção para respostas vazias, timeouts, erros 400 de comprimento de contexto, fila e roteadores
Começando	Modelos locais do zero: LM Studio ou Docker, no que modelos pequenos são bons, quais cabem na sua VRAM
Configuração do LM Studio, Ollama e vLLM	Guias de backend, cada um com as armadilhas que causam falhas silenciosas
Teste de shakedown	A verificação de ponta a ponta, como script ou como prompt para o Claude
Guia do desenvolvedor	Arquitetura, contribuição, processo de release

Desenvolvimento

git clone https://github.com/houtini-ai/houtini-lm.git
cd houtini-lm
npm install
npm test             # build + unit tests
npm run shakedown    # end-to-end self-test against a live endpoint

DEVELOPER.md cobre a arquitetura, o pipeline de modelos pensantes, detecção de backend, o cache de desempenho SQLite e como adicionar novas ferramentas ou backends. Se você encontrar uma família de modelos que o houtini-lm lida mal, abra uma issue com a saída discover e eu darei uma olhada.

Boa sorte, e me conte como foi!

Licença

Apache-2.0