- pxpipe é um proxy local que transforma grandes contextos de requisições do Claude Code em imagens PNG para reduzir tokens de entrada, e afirma reduzir a cobrança ponta a ponta em cerca de 59~70% com base no preço de tabela atual do Fable
- O princípio central é que o custo de tokens de imagem é determinado pelo tamanho em pixels, não pela quantidade de texto dentro da imagem; textos densos como código, JSON e saída de ferramentas, no tráfego real do Claude Code, contêm cerca de 3,1 caracteres por token de imagem e cerca de 1 caractere por token de texto
- A compressão mira
tool_result grandes, histórico antigo recolhido, prompts de sistema estáticos e documentação de ferramentas; turnos recentes, mensagens do usuário, saídas do modelo, prosa esparsa e modelos fora da lista de permissão passam como texto puro
- Por ser uma abordagem com perdas, a recuperação exata de strings hex de 12 caracteres foi 13/15 no Fable 5 e 0/15 no Opus; omissões podem aparecer não como erros, mas como respostas plausíveis incorretas, então valores que exigem exatidão byte a byte, como IDs, hashes e segredos, devem permanecer em texto
- Os modelos-alvo padrão são
claude-fable-5,gpt-5.6; Opus 4.7/4.8 e GPT 5.5 são usados apenas por opt-in devido à pior leitura de contexto em imagem, e a aplicação real e a economia podem ser verificadas por requisição em ~/.pxpipe/events.jsonl
O custo que o pxpipe tenta reduzir
- pxpipe é um proxy local que renderiza grandes contextos como imagens para reduzir os tokens de entrada do Claude Code
- O alvo são blocos de entrada volumosos no corpo da requisição, como prompts de sistema, documentação de ferramentas, histórico passado e grandes saídas de ferramentas
- A saída do modelo não é comprimida, e o streaming de respostas funciona normalmente
- O custo em tokens de uma imagem é definido não pela quantidade de caracteres dentro dela, mas pelo tamanho em pixels
- No tráfego real do Claude Code, conteúdo denso contém cerca de 3,1 caracteres por token de imagem
- Tokens de texto foram medidos em torno de 1 caractere
- Um render de exemplo colocou cerca de 48 mil caracteres de prompt de sistema e documentação de ferramentas em uma única imagem de 1573×1248; em texto seriam necessários cerca de 25 mil tokens, enquanto em imagem são cerca de 2,7 mil tokens de imagem
Execução e dashboard
npx pxpipe-proxy # proxy on 127.0.0.1:47821
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude # point Claude Code at it
- O proxy roda em
127.0.0.1:47821
- O dashboard é disponibilizado em
http://127.0.0.1:47821/
- Número de tokens economizados
- Comparação lado a lado da conversão texto→imagem
- Kill switch
- Chips de modelo em tempo real
- Turnos recentes são mantidos como texto, enquanto prompts de sistema, documentação de ferramentas e histórico antigo volumoso são convertidos em imagem
Resultados mostrados na demo
- Fable 5 é o padrão e é apresentado no README como modelo com leitura 100/100
- Acertou 10/10 contagens exatas de tokens em 39 arquivos filler convertidos em imagem
- Coincidiu linha a linha com os resultados de
grep
- Acertou aritmética de ledger em várias etapas
- O custo da sessão é apresentado como US$ 6,06 com pxpipe e US$ 42,21 em texto comum
- No lado do pxpipe, foi necessário um nudging para cumprir o formato de saída de uma linha solicitado
- Opus 4.8 vem desativado por padrão
- O needle em texto foi lido em ambos os lados
- O phrase-count convertido em imagem não foi lido pelo Opus, e o pxpipe expôs a falha sem inventar um número
- Por essa taxa de leitura incorreta, o Opus é alvo de opt-in
Precisão e perdas
- pxpipe é uma forma de compressão com perdas
- Em conteúdo denso em imagem, os resultados de recuperação exata de strings hex de 12 caracteres variam bastante por modelo
- Fable 5: 13/15
- Opus: 0/15
- Omissões podem aparecer não como erros, mas como confabulação silenciosa
- Valores que precisam de precisão byte a byte, como IDs, hashes e segredos, devem permanecer como texto
- Ainda não há um guard dedicado de risco de verbatim embutido
- Um subagent que usa um modelo fora da lista de permissão pode passar como texto
CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6model: sonnet no frontmatter do agent
Benchmarks e medições
- O benchmark baseado em novos problemas com números aleatórios usa questões que têm baixa probabilidade de terem sido memorizadas pelo modelo
| Teste |
N |
Texto |
Imagem pxpipe |
Tokens |
novel arithmetic, claude-fable-5 |
100 |
100% |
100% |
−38% |
novel arithmetic, claude-opus-4-8 |
100 |
100% |
93% |
−38% |
| gist recall A/B, Fable 5 |
98/arm |
98/98 |
98/98 |
- |
| state tracking, Fable 5 |
18/arm |
18/18 |
18/18 |
- |
| never-stated facts confabulation, Fable 5 |
16/arm |
0/16 |
0/16 |
- |
| verbatim 12-char hex recall, dense render, Opus |
15 |
15/15 |
0/15 |
- |
| verbatim 12-char hex recall, dense render, Fable 5 |
15 |
- |
13/15 |
- |
- O piloto SWE-bench Lite foi 10/10 em ambos os lados, com tamanho de requisição −65%
- O SWE-bench Pro foi ON 14/19, OFF 15/19, com tamanho de requisição −60%
- O julgamento coincidiu em 18/19
- Um caso de split foi resolvido novamente em 3/3 em execuções replicadas
- O README trata isso como variação entre execuções, não como problema de compressão
- Há a ressalva de que o tamanho da amostra é pequeno
- O GSM8K teve 96% com imagem, mas como pode estar incluído nos dados de treinamento, o README prioriza a avaliação novel-number
Como funciona
tool_result string ──► wrap at 1928px-wide columns ──► pack ~92,000 chars/page ──► PNG[]
- O proxy intercepta
/v1/messages e reescreve entradas volumosas adequadas como image block
- Blocos convertidos são reinseridos de forma amigável ao cache, preservando o prefixo estático para que o prompt caching continue funcionando
- Uma imagem de 1928×1928 usa cerca de 4.761 vision tokens e contém cerca de 92.000 caracteres
- Para o texto vencer, precisaria passar de cerca de 19 caracteres/token; o tráfego do Claude Code foi medido em cerca de 1,91 com N=391
- Um estimador por requisição decide se deve converter para imagem, e prosa esparsa é mantida como texto
- Eventos são registrados em
~/.pxpipe/events.jsonl
O que é comprimido e o que fica intacto
- Os alvos de compressão são três blocos de entrada, todos atrás de um gate de rentabilidade
- Corpo de
tool_result denso em tokens com cerca de 6 mil caracteres ou mais
- Histórico antigo recolhido atrás do live tail
- Slab estático de prompt de sistema e documentação de ferramentas
- Também são explicitados os itens que passam intactos
- Mensagens do usuário
- Turnos recentes
- Saídas do modelo
- Prosa esparsa
- Blocos pequenos demais para gerar ganho
- Modelos fora da lista de permissão
- O escopo padrão é Fable 5 e GPT 5.6
- Opus 4.8 e GPT 5.5 têm pior desempenho de leitura de conteúdo em imagem, então precisam ser ativados explicitamente pelo dashboard ou por
PXPIPE_MODELS
PXPIPE_MODELS=off desativa a conversão para imagem- No caminho GPT, definições de ferramentas são mantidas como JSON nativo e não usam marcadores Anthropic
cache_control
Como o custo é calculado
- A taxa de economia do título se baseia na cobrança total, não apenas no slice de entrada
- Em um snapshot de 13.709 requisições, US$ 100 caíram para cerca de US$ 41, calculando 59% de economia
- Em um trace posterior de 8.904 requisições comprimidas, a medição ficou em cerca de 70%
- Considerando apenas requisições comprimidas, o nível fica em 72~74%, mas o README não usa isso como chamada principal
- Para cada POST em
/v1/messages, um counterfactual gratuito de count_tokens é executado em paralelo sobre o corpo original não comprimido
- O uso efetivamente cobrado é lido no bloco usage da resposta da Anthropic
- O uso original e o real são registrados na mesma linha de
~/.pxpipe/events.jsonl, evitando confundidores de número de turnos ou variação entre execuções
- A conversão para dólares usa a proporção do preço de tabela do Fable 5
- input ×1.0
- cache write ×1.25
- cache read ×0.1
- output ×5
- Os preços de cache são aplicados igualmente dos dois lados, então o desconto de cache não é contado em duplicidade como economia
Uso como biblioteca
import { renderTextToPngs, transformAnthropicMessages } from "pxpipe";
const imgs = await renderTextToPngs(toolResultText); // RenderedImage[]
const { body, applied, info } = await transformAnthropicMessages({
body: requestBytes,
model: "claude-fable-5",
});
- Também pode ser usado como biblioteca sem o proxy
options.keepSharp(block) fixa um bloco específico como textooptions.emitRecoverable retorna o original de blocos convertidos em imagem- O runtime é Pure JS e suporta Node e edge/Workers
@napi-rs/canvas é usado apenas em build time- A API completa fica em
src/core/index.ts
Falhas reais e limitações
- Em algumas semanas de uso cotidiano, houve um caso em que, ao recuperar o nome de uma pessoa em um histórico de chat convertido em imagem, o modelo errou com confiança
- Sessões de programação toleram esse modo de falha porque releem arquivos antes de editar, mas recuperação em chat puro não tem a mesma validação
- A legibility audit mede a recuperação exata de strings em páginas renderizadas
- A leitura cega de identifiers densos chegou no máximo a 63%
- Todos os misses foram previstos por uma matriz de confusabilidade de glifos
- Foi aplicada uma mitigação que limita a geometria da página para se adequar ao cap de resample da API
- Identifiers exatos, como SHA e números, são incluídos também em texto
- As limitações também são explicitadas
- Recall verbatim baseado em imagem é difícil de confiar
- Requisições grandes acrescentam latência de codificação PNG antes do envio
- ASCII/Latin-1 foram bem testados
- CJK funciona, mas é tratado de forma conservadora
Desenvolvimento e roadmap
pnpm install && pnpm test
pnpm run build # regenerates dist/
- Os comandos de desenvolvimento consistem em instalação/teste e build
- A licença é MIT
- O roadmap é apresentado apenas como hipótese; se não vier acompanhado de números e tamanho de amostra, não deve ser tratado como claim
- Renderização de glifos mais nítida
- Se bulk convertido em imagem pode aumentar em cerca de 2× o contexto efetivo na mesma janela de 1M
- Se um active context menor aumenta a precisão em tarefas longas
1 comentários
Comentários do Hacker News
Pelo que entendo, no Gemini, ao processar PDFs, primeiro é feito OCR, depois texto e imagens são enviados juntos ao modelo, e os tokens de texto não são cobrados
Se o backend do Claude estiver fazendo a mesma coisa, esse hack parece mais uma brecha no modelo de cobrança por tokens, e, se o Claude passar a funcionar como o Gemini, há uma boa chance de isso ser bloqueado no futuro
Mas, nos comentários abaixo, alguém menciona que o DeepSeek melhorou bastante a taxa de compressão com tokens visuais: https://news.ycombinator.com/item?id=48777848
Não entendo todos os detalhes técnicos internos, então ainda tenho dificuldade de entender como o caminho via OCR poderia levar a redução no consumo total de energia ou computação
Uma forma de colocar imagens em um LLM é dividir a imagem em tiles, passar esses tiles por uma rede neural vision encoder para gerar tokens visuais e então inserir esses tokens no LLM como se fossem tokens de texto. Naturalmente, o vision encoder e o LLM são treinados para se entenderem. Esse tipo de abordagem é chamado de modelo de OCR fim a fim
Depois que você tem um modelo treinado assim, pode aumentar ou reduzir a imagem do documento e ver como isso muda o número de tokens visuais usados para representar o mesmo documento de texto; também dá para ajustar parâmetros como tamanho dos patches ou complexidade do vision encoder
Os resultados foram bem bons e, em alguns testes, reduziram os tokens de entrada em 90% mantendo 97% do desempenho na saída
Tentei algo parecido no ano passado com modelos da OpenAI e, naquela época, ajudava a reduzir os tokens do prompt, mas acabava exigindo muito mais tokens de conclusão, então no fim saía mais caro e mais lento
https://pagewatch.ai/blog/post/llm-text-as-image-tokens/
Ai, isso dói nos olhos. Parece um README codado no vibe
Por exemplo:
Dá para criar coisas realmente úteis com IA, especialmente em áreas nas quais você já tem expertise. Mas, nesse caso, é preciso 1) deixar claro que usou ajuda de IA e 2) explicar com as próprias palavras o que exatamente foi feito. Melhor ainda se conseguir falar também sobre as limitações de trabalhar com IA
Isso passa a confiança de que “vale a pena mexer no que essa pessoa fez, ela entende bem o que construiu”
Hoje, 99% do que aparece é resultado de gente trabalhando em áreas que não entende nem um pouco, então, quando vejo um README desses, simplesmente fecho a aba
Isso parece um hack de precificação que desperdiça recursos. Se a brecha for fechada, o preço do OCR não deveria subir?
Pensando bem, faz sentido. Humanos também leem código palavra por palavra, mas na maior parte do tempo só passam os olhos e reconhecem padrões para entender aproximadamente o que ele faz. Só focam em trechos específicos quando precisam responder a uma pergunta específica
Dá para ver os humanos como naturalmente fazendo uma otimização por desvio semelhante
Post relacionado: https://blog.can.ac/2026/06/10/snapcompact/
É preciso tomar cuidado com essa abordagem. Pode ser que a redução de custo aconteça, na verdade, porque você está sendo redirecionado para um modelo diferente e de desempenho inferior
Por fora parece o Fable, mas na prática pode não ser. Nesse caso, você só está criando trabalho extra à toa, e talvez fosse melhor simplesmente voltar o modelo para opus 4.8
Parece que o Oh-My-Pi(OMP.sh) usa imagens para compressão de contexto. O OMP foi construído em cima do agente de programação Pi
Também existe um whitepaper da DeepSeek sobre essa técnica: https://www.seangoedecke.com/text-tokens-as-image-tokens
Vi um tweet de alguém há algum tempo, provavelmente Carmack, Geohot ou Karpathy, dizendo algo na linha de que imagens podem ser uma opção melhor
Desde então, venho usando imagens junto com prompts de frases bem simples para informar ao agente o que está acontecendo naquele momento, e às vezes nem coloco texto nenhum no prompt
Funcionou muito bem
Só que isso não é exatamente a mesma coisa que o Karpathy estava dizendo. Ainda assim, essa ideia acabou levando a um fluxo de trabalho melhor
Desculpem, mas isso é absurdo. Funciona e é esperto, mas claramente é uma forma de contornar uma falha de precificação
Assim como as pessoas começaram a criar cobras por causa de recompensas por cobras, isso explora e incentiva desperdício
No fim, acho que a culpa é da estrutura ruim de preços da Anthropic, que tornou esse tipo de arbitragem possível. Mas, até que isso seja corrigido, é revoltante pensar na enxurrada adicional de lixo digital completamente desnecessário que vai ser produzida por gente abusando disso