O llm-openrouter 0.7 traz traces de raciocínio e ferramentas server-side na CLI

Se você prototipa com LLMs↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → no terminal, provavelmente já esbarrou no llm, a ferramenta de linha de comando de Simon Willison. O plugin llm-openrouter é o que conecta essa CLI ao OpenRouter, o roteador que dá acesso a centenas de modelos (OpenAI, Anthropic, Google, Qwen, DeepSeek, Llama e por aí vai) através de uma única API e uma única chave. A versão 0.7, lançada em 21 de agosto, é uma atualização pequena em linhas de changelog, mas destrava recursos que valem a pena para quem faz experimento de IA no dia a dia.

O que o plugin resolve

A proposta central não mudou: em vez de instalar SDK de cada provedor, gerenciar N chaves e adaptar código para cada API, você fala com tudo por um endpoint só. Na prática, depois de instalar o plugin e configurar a chave, você lista e chama qualquer modelo disponível no OpenRouter direto do shell:

llm install llm-openrouter
llm keys set openrouter
# cole sua chave do OpenRouter

llm -m openrouter/anthropic/claude-sonnet-4 'explique async/await em JS'
llm models list | grep openrouter

Para o dev brasileiro isso tem um valor concreto: comparar modelos lado a lado sem criar conta em cada provedor, sem lidar com cartão internacional em cinco lugares diferentes e sem reescrever o prompt para cada SDK. Um crédito no OpenRouter cobre todos. É a forma mais rápida de responder "qual modelo resolve melhor esse caso?" antes de comprometer o projeto com um fornecedor.

Reasoning traces à mostra

A novidade mais interessante da 0.7 vem de carona com a compatibilidade com o LLM 0.32: o plugin agora exibe os traces de raciocínio dos modelos que expõem essa informação. Modelos de raciocínio (como as famílias que fazem "thinking" antes de responder) produzem uma cadeia de pensamento intermediária, e poder ver isso na CLI ajuda a entender por que o modelo chegou a determinada resposta, útil quando você está depurando um prompt que dá resultado estranho ou avaliando se vale o custo extra de tokens de raciocínio.

Outra mudança de fundo: os modelos passam a usar a implementação da Responses API do OpenRouter. É a API mais nova de orquestração (a mesma linha que a OpenAI adotou para unificar chamadas com ferramentas e estado), e adotá-la aqui é o que abre espaço para o próximo item.

Três ferramentas server-side

A 0.7 adiciona três ferramentas executadas no lado do servidor do OpenRouter, ativadas pela flag -T:

• WebSearch: o modelo pode buscar na web durante a resposta.
• WebFetch: buscar e ler o conteúdo de uma URL específica.
• Shell: executar comandos de shell.

O uso é direto:

llm -m openrouter/openai/gpt-5 -T WebSearch \
  'quais as novidades do Python 3.14?'

A sacada de serem server-side é que a execução acontece na infraestrutura do OpenRouter, não na sua máquina. Isso simplifica o setup (você não precisa montar o loop de tool calling nem hospedar as ferramentas), mas tem contrapartidas que vale ter em mente. WebSearch e WebFetch significam que o modelo puxa conteúdo externo para dentro do contexto, com todo o risco de injeção de prompt que isso carrega. E Shell executando remotamente é poderoso e perigoso na mesma medida: pense duas vezes antes de soltar isso em cima de um prompt não confiável. A fonte não detalha o sandboxing por trás dessas execuções, então trate como capacidade de experimentação, não como algo para colocar em produção sem entender o modelo de isolamento.

Para quem vale e para quem não vale

Vale muito se você é o tipo de dev que testa modelo novo toda semana, faz benchmark informal de qual LLM resolve determinada tarefa, ou quer um playground de agentes sem montar infra. A combinação llm + llm-openrouter te dá isso em dois comandos, com histórico de conversas em SQLite local (recurso do próprio llm) para você revisitar experimentos depois.

Não vale como substituto de uma stack de produção. O OpenRouter adiciona uma camada de latência e uma margem de custo sobre o preço direto dos provedores, e você fica dependente da disponibilidade dele como intermediário. Para uma aplicação que já sabe qual modelo usa e precisa de SLA, ir direto no provedor tende a fazer mais sentido. As ferramentas server-side, em especial, são ótimas para prototipar comportamento de agente, mas exigem cautela de segurança antes de qualquer uso sério.

Como colocar a mão

Pré-requisitos: Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) → e o llm na versão 0.32 ou superior. Fluxo mínimo do zero:

pip install llm            # ou: uv tool install llm
llm install llm-openrouter
llm keys set openrouter

# um experimento comparando dois modelos no mesmo prompt
llm -m openrouter/deepseek/deepseek-chat 'resuma a diferença entre RAG e fine-tuning'
llm -m openrouter/qwen/qwen-3.8-27b       'resuma a diferença entre RAG e fine-tuning'

O changelog completo da 0.7 e as instruções estão no post de release de Simon Willison. Se você ainda não usa o llm na rotina, essa é uma boa desculpa: é a maneira mais barata de manter o dedo no pulso de quais modelos estão valendo a pena, sem casar com nenhum provedor.

Fonte: Simon Willison