Você já parou pra calcular quanto gasta por mês com tokens de input no Claude Code? Eu parei. E o número me fez engolir o café errado.

O problema é simples: quando você usa o Claude Code (ou qualquer agente de IA que lê arquivos, roda comandos e analisa logs), a maior parte do custo não vem das respostas. Vem do contexto. System prompts, documentação de tools, histórico de conversa, saída de comandos. Tudo isso é texto, e texto custa caro.

Um dev chamado teamchong teve uma ideia que, à primeira vista, parece absurda: e se a gente transformar esse texto em imagem antes de enviar pro modelo? Tipo, renderizar o conteúdo como PNG e mandar como input visual?

O resultado é o pxpipe, um proxy local que faz exatamente isso. E os números são reais: 59% a 70% de redução na conta.

A matemática que ninguém te contou sobre tokens visuais

Pra entender por que isso funciona, você precisa saber como o Claude calcula tokens de imagem. A fórmula é direta:

tokens = (largura_px × altura_px) / 750

Ou, de forma equivalente, o modelo divide a imagem em patches de 28×28 pixels. Cada patch = 1 token visual. Uma imagem de 1928×1928 pixels custa aproximadamente 4.761 tokens visuais.

Agora vem o pulo do gato: o custo do token visual depende só das dimensões da imagem, não da quantidade de informação dentro dela. Você pode ter uma imagem em branco ou uma imagem com 92 mil caracteres de código renderizado. O custo é o mesmo.

Compare isso com texto puro, onde cada token representa em média 1,91 caracteres no tráfego típico do Claude Code. Aqui está a conta que muda tudo:

Uma página de 1928×1928 pixels comporta cerca de 92 mil caracteres. Em texto, isso custaria algo em torno de 48 mil tokens. Em imagem, custa 4.761 tokens. Uma compressão de mais de 10x no custo de input.

Como o pxpipe funciona na prática

Antes de entrar nos detalhes, vale contextualizar: o pxpipe não é um wrapper, não é um SDK alternativo, não é um fork do Claude Code. É um proxy HTTP local, transparente, que fica entre o Claude Code e a API da Anthropic. Ele intercepta as requests no endpoint /v1/messages, faz a mágica de compressão, e encaminha pra API real. Do ponto de vista do Claude Code, nada mudou. Do ponto de vista da sua carteira, tudo mudou.

Você roda ele na sua máquina e aponta o Claude Code pra ele:

# Instala e roda o proxy
npx pxpipe-proxy

# Aponta o Claude Code pro proxy
export ANTHROPIC_BASE_URL=http://localhost:47821

A partir daí, toda request que o Claude Code faz passa pelo pxpipe antes de chegar na Anthropic. O proxy analisa o conteúdo e decide o que converter:

O que vira imagem:

• Saídas grandes de ferramentas (leitura de arquivos, logs, output de comandos acima de ~6k caracteres)
• Histórico antigo de conversa (turns que já ficaram pra trás)
• System prompt e documentação de tools (conteúdo estático e repetitivo)

O que continua como texto:

• Mensagens recentes do usuário
• Respostas do modelo
• Payloads pequenos
• Qualquer conteúdo que precisa de precisão byte-a-byte (hashes, IDs, secrets)

O pipeline de renderização funciona assim:

1. O texto é minificado (whitespace removido) e redistribuído em colunas
2. O conteúdo é quebrado em linhas de 1928 pixels de largura
3. Quebras de linha originais são marcadas com o símbolo ↵ pra o modelo saber onde estavam
4. Um banner de instrução é renderizado no topo de cada página, orientando o modelo a tratar aquilo como texto
5. O resultado é um PNG monocromático com fonte monospace otimizada pra OCR

Cada página comporta aproximadamente 92 mil caracteres. Na maioria dos casos, um system prompt inteiro do Claude Code (que facilmente chega a 25 mil tokens de texto) cabe em uma única imagem de ~2.700 tokens visuais.

A parte engenhosa é que o pxpipe preserva compatibilidade com prompt caching. O system prompt e a documentação de tools, que normalmente ficam cacheados entre requests, continuam sendo cacheáveis quando convertidos em imagem. Isso significa que você não perde o desconto de 90% no cache read só porque mudou o formato.

Os benchmarks que validam a ideia

Eu sei o que você está pensando: “tá, mas o modelo consegue ler texto em imagem tão bem quanto texto puro?”

A resposta curta é: quase sempre sim. A resposta longa tem nuances importantes.

Teste aritmético (100 casos)

Em testes com operações aritméticas novas (não memorizáveis), o Fable 5 acertou 100 de 100 casos com o conteúdo comprimido em imagem. Nenhuma degradação. A redução de tokens foi de 38%.

SWE-bench Lite (10 instâncias)

Esse é o benchmark mais relevante pra quem usa Claude Code pra resolver bugs reais. Os resultados:

Mesma taxa de resolução, metade do custo. Isso não é benchmark de laboratório, são tasks reais de engenharia de software.

SWE-bench Pro (19 pares)

No benchmark mais difícil, os resultados foram:

A diferença de 1 task foi investigada: rodando o mesmo par 3 vezes, o resultado variou igualmente nos dois braços. Ou seja, é variância natural do modelo, não degradação causada pela compressão.

O elefante na sala: perda de precisão

Aqui é onde a coisa fica honesta (e eu respeito o autor do pxpipe por isso, porque ele documenta a limitação em vez de esconder).

Quando o modelo precisa recuperar uma string exata de dentro do conteúdo renderizado como imagem, a taxa de acerto cai. Em testes com strings hexadecimais de 12 caracteres dentro de contexto denso:

Isso significa que se o seu workflow depende de ler um hash SHA exato, um UUID, ou um número de ID específico de dentro de um arquivo grande que foi renderizado como imagem, existe risco de o modelo inventar um valor plausível. E o pior: ele inventa com confiança, sem avisar que não tem certeza.

Na prática, pra workflows de coding onde o agente relê o arquivo fonte antes de editar (que é o comportamento padrão do Claude Code), isso raramente é problema. O agente usa a imagem pra entender o contexto geral e depois lê o arquivo real como texto antes de fazer qualquer modificação. É a mesma lógica de um dev que dá uma olhada rápida no arquivo pra lembrar a estrutura e depois abre ele de verdade pra editar.

O próprio autor do pxpipe descreve isso como “lossy compression for agentic workflows”: você aceita uma perda marginal de precisão em troca de uma economia brutal de tokens. Em 95% dos cenários de uso, a perda é imperceptível. Nos outros 5%, você precisa saber onde pisar.

Pra mitigar:

# Desabilitar imaging completamente
PXPIPE_MODELS=off

# Rotear subagentes que precisam de precisão pra um modelo sem compressão
CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6

A economia real: quanto você economiza?

Vamos fazer a conta com os preços atuais do Fable 5 (que é o modelo padrão otimizado pro pxpipe):

Considere uma sessão típica de Claude Code com:

• System prompt + tool docs: ~25k tokens de input
• Histórico de conversa: ~15k tokens
• Saída de ferramentas (file reads, grep, etc): ~30k tokens
• Mensagens recentes (não comprimidas): ~5k tokens

Sem pxpipe: 75k tokens de input por request.

Com pxpipe: Os ~70k tokens compressíveis viram imagens. Com a taxa de compressão medida de 3,1 chars por image-token vs 1 char por text-token, esses 70k tokens se transformam em ~22,5k tokens visuais. Mais os 5k de texto. Total: ~27,5k tokens.

Redução: 63% no input. Se você gasta $200/mês com input tokens, cai pra $74.

A documentação do projeto reporta números de 59% a 70% de redução end-to-end (considerando todas as requests, incluindo as que passam sem compressão) e 72% a 74% só nas requests comprimidas.

Quando usar (e quando não usar)

O pxpipe faz sentido quando:

• Você usa Claude Code intensivamente e a conta de tokens está alta
• Seu workflow é majoritariamente agêntico (leitura de arquivos, execução de comandos, ciclos de edit/test)
• Você trabalha com o Fable 5, que tem a melhor taxa de acerto em OCR de conteúdo renderizado
• O conteúdo do seu contexto é denso (código, logs, JSON), não prosa esparsa

O pxpipe não faz sentido quando:

• Você precisa de precisão absoluta em strings exatas dentro do contexto (criptografia, hashes, IDs sensíveis)
• Seu contexto é majoritariamente prosa curta (a compressão só compensa em blocos densos acima de ~6k chars)
• Você usa Opus 4.8, que tem taxa de OCR significativamente pior (o projeto desabilita Opus por padrão)
• Seu tráfego é baixo o suficiente pra que a economia não justifique a complexidade

Como configurar em 5 minutos

A instalação é trivial:

# Roda o proxy (sem instalar globalmente)
npx pxpipe-proxy

# Em outro terminal, configura o Claude Code
export ANTHROPIC_BASE_URL=http://localhost:47821

# Abre o Claude Code normalmente
claude

O proxy sobe um dashboard em http://127.0.0.1:47821/ onde você monitora em tempo real:

• Quantos tokens foram economizados por request
• Quais blocos foram convertidos pra imagem
• Toggle de modelos (liga/desliga imaging por modelo sem reiniciar)

Pra configuração permanente, crie o arquivo ~/.config/pxpipe/config.json:

{
  "models": "claude-fable-5,gpt-5.6"
}

Cada request gera um evento em ~/.pxpipe/events.jsonl com o counterfactual (quanto custaria sem compressão), então você pode auditar a economia real a qualquer momento.

Isso é um hack ou uma feature?

A pergunta que fica é: a Anthropic vai fechar essa brecha?

Por enquanto, não há nada nos termos de uso que proíba converter texto em imagem antes de enviar. O modelo está recebendo a mesma informação, só em formato diferente. E o pricing de imagem segue a fórmula documentada.

Mas vale lembrar que essa assimetria de preço existe por um motivo: processar imagens exige compute diferente de processar texto. Se muita gente começar a explorar isso, a Anthropic pode ajustar o pricing de tokens visuais pra fechar o gap.

Historicamente, exploits de pricing em APIs de IA têm vida útil limitada. Quem lembra do truque de mandar texto como PDF pro GPT-4 pra economizar tokens? Durou uns 3 meses.

Então minha recomendação é: se a economia faz diferença pra você, aproveite agora. Mas não construa sua arquitetura inteira em cima dessa arbitragem. O pxpipe é uma otimização, não uma fundação.

O que isso revela sobre o futuro do pricing de IA

Além da utilidade prática, o pxpipe expõe algo mais profundo: o modelo de pricing por token está ficando cada vez mais difícil de sustentar.

Quando um proxy consegue cortar 70% da sua conta simplesmente mudando o formato do input, sem alterar a informação, fica claro que “contar tokens” é uma métrica cada vez menos conectada ao custo real de compute.

Não é coincidência que a Anthropic já oferece pricing por sessão no Claude Code (assinatura fixa), que a OpenAI experimentou pricing por tarefa, e que modelos menores com throughput otimizado estão ganhando mercado.

O pxpipe é, no fundo, um sintoma de que a indústria precisa evoluir seus modelos de cobrança. A tendência já está clara: pricing por resultado (quanto valor o modelo gerou) em vez de pricing por input (quantos tokens você mandou). Enquanto essa transição não se completa, quem souber explorar as brechas economiza. E quem não souber, paga a conta cheia.

Pra quem desenvolve com IA e quer ir além do básico, o pxpipe também funciona como biblioteca. Você pode importar as funções diretamente no seu código TypeScript:

import { renderTextToPngs, transformAnthropicMessages } from "pxpipe";

// Renderizar texto como imagens
const imgs = await renderTextToPngs(toolResultText);

// Transformar um body de request da Anthropic
const { body, applied, info } = await transformAnthropicMessages({
  body: requestBytes,
  model: "claude-fable-5",
});

Isso abre possibilidades pra quem está construindo agentes customizados e quer integrar a compressão direto no pipeline, sem depender do proxy HTTP.

O repositório está em github.com/teamchong/pxpipe. A documentação é surpreendentemente honesta sobre as limitações. Os 376 testes passam. E a economia é real.

Agora me diz: você teria coragem de converter seu contexto inteiro em PNG e confiar que o Claude vai ler tudo certinho?

Fonte de inspiração: pxpipe no GitHub (trending no Hacker News)