Fable reduce costos un 60%: convertir código en imágenes y hacer que el modelo haga OCR

 (github.com/teamchong)
4 puntos por GN⁺ 5 시간 전 | 1 comentarios | Compartir por WhatsApp
  • pxpipe afirma que convierte el gran contexto de las solicitudes de Claude Code en imágenes PNG en un proxy local para reducir tokens de entrada, y que baja el cobro end-to-end aproximadamente 59~70% según el precio de lista actual de Fable
  • El principio clave es que el costo de tokens de imagen se determina por el tamaño en píxeles, no por la cantidad de texto dentro de la imagen; textos densos como código, JSON y salidas de herramientas contienen, en tráfico real de Claude Code, unas 3.1 letras por token de imagen y alrededor de 1 letra por token de texto
  • Los objetivos de compresión son tool_result grandes, historial plegado antiguo, prompts de sistema estáticos y documentación de herramientas; los turnos recientes, mensajes de usuario, salidas del modelo, prose dispersa y modelos fuera de la lista permitida pasan tal cual como texto
  • Al ser un método con pérdida, la recuperación exacta de cadenas hex de 12 caracteres fue 13/15 en Fable 5 y 0/15 en Opus; las omisiones pueden aparecer no como errores sino como respuestas plausibles pero incorrectas, por lo que valores que requieren exactitud byte a byte, como IDs, hashes y secretos, deben mantenerse como texto
  • Los modelos objetivo predeterminados son claude-fable-5,gpt-5.6; Opus 4.7/4.8 y GPT 5.5 solo se usan con opt-in por su peor desempeño al leer contexto de imagen, y la aplicación real y el ahorro pueden revisarse por solicitud en ~/.pxpipe/events.jsonl

El costo que pxpipe busca reducir

  • pxpipe es un proxy local que renderiza contextos grandes como imágenes para reducir los tokens de entrada de Claude Code
  • Apunta a bloques de entrada voluminosos en el cuerpo de la solicitud, como prompts de sistema, documentación de herramientas, historial pasado y salidas grandes de herramientas
  • No comprime la salida del modelo, y el streaming de respuestas funciona normalmente
  • El costo en tokens de una imagen se determina por el tamaño en píxeles, no por la cantidad de caracteres dentro de la imagen
    • En tráfico real de Claude Code, el contenido denso contiene unas 3.1 letras por token de imagen
    • Los tokens de texto se midieron en torno a 1 letra por token
  • Un render de ejemplo metió unas 48k letras de prompt de sistema y documentación de herramientas en una sola imagen de 1573×1248; como texto requeriría unos 25k tokens, y como imagen unos 2.7k tokens de imagen

Ejecución y 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
  • El proxy se ejecuta en 127.0.0.1:47821
  • El dashboard se ofrece en http://127.0.0.1:47821/
    • Cantidad de tokens guardados
    • Comparación lado a lado de la conversión texto→imagen
    • Kill switch
    • Chips de modelo en tiempo real
  • Los turnos recientes se mantienen como texto, y el prompt de sistema, la documentación de herramientas y el historial masivo antiguo se convierten en imágenes

Resultados mostrados en la demo

  • Fable 5 es el valor predeterminado, y el README lo presenta como un modelo con lectura 100/100
    • Acertó 10/10 los conteos exactos de tokens en 39 archivos filler convertidos en imagen
    • Coincidió línea por línea con los resultados de grep
    • Acertó cálculos de ledger de varios pasos
    • El costo de la sesión se presenta como US$6.06 usando pxpipe, frente a US$42.21 con texto normal
    • Del lado de pxpipe hizo falta un nudging para ajustarse al formato de salida de una sola línea solicitado
  • Opus 4.8 está desactivado por defecto
    • El needle de texto se leyó en ambos lados
    • El phrase-count convertido en imagen no fue leído por Opus, y pxpipe expuso el fallo sin inventar números
    • Por esta tasa de lectura errónea, Opus queda como opción con opt-in

Precisión y pérdida

  • pxpipe usa compresión con pérdida
  • En contenido de imagen denso, los resultados de recuperación exacta de cadenas hex de 12 caracteres varían mucho según el modelo
    • Fable 5: 13/15
    • Opus: 0/15
  • Las omisiones pueden aparecer no como errores sino como confabulación silenciosa
  • Los valores que requieren exactitud a nivel de bytes, como IDs, hashes y secretos, deben mantenerse como texto
  • Todavía no incluye un guard dedicado para riesgo de verbatim
  • Un subagent que use un modelo fuera de la lista permitida puede pasar como texto
    • CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6
    • model: sonnet en el frontmatter del agent

Benchmarks y mediciones

  • Usa un benchmark basado en nuevos problemas con números aleatorios, para que sea poco probable que el modelo los haya memorizado
Prueba N Texto Imagen 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 -
  • El piloto de SWE-bench Lite fue 10/10 en ambos lados y el tamaño de solicitud bajó 65%
  • SWE-bench Pro fue ON 14/19 y OFF 15/19, con tamaño de solicitud 60% menor
    • El dictamen coincidió en 18/19
    • Un caso dividido se resolvió de nuevo 3/3 en ejecuciones replicadas
    • El README lo trata como variación entre ejecuciones, no como un problema de compresión
    • Incluye la salvedad de que el tamaño de muestra es pequeño
  • GSM8K obtuvo 96% en modo imagen, pero como podría estar incluido en los datos de entrenamiento, el README prioriza la evaluación con números novedosos

Cómo funciona

tool_result string ──► wrap at 1928px-wide columns ──► pack ~92,000 chars/page ──► PNG[]
  • El proxy intercepta /v1/messages y reescribe las entradas masivas adecuadas como image block
  • Los bloques convertidos se reinsertan de forma amigable para caché, preservando el prefijo estático para que prompt caching siga funcionando
  • Una imagen de 1928×1928 usa unos 4,761 vision tokens y contiene cerca de 92,000 caracteres
  • Para que el texto gane tendría que superar unas 19 letras/token, pero el tráfico de Claude Code se midió en alrededor de 1.91 con N=391
  • Un estimador por solicitud decide si se convierte en imagen, y la prose dispersa se mantiene como texto
  • Los eventos se registran en ~/.pxpipe/events.jsonl

Qué comprime y qué deja tal cual

  • Los objetivos de compresión son tres bloques de entrada, todos detrás de una compuerta de rentabilidad
    • Cuerpos tool_result densos en tokens de unas 6k letras o más
    • Historial plegado antiguo detrás del live tail
    • Slab estático de prompt de sistema y documentación de herramientas
  • También se especifican los elementos que pasan tal cual
    • Mensajes de usuario
    • Turnos recientes
    • Salidas del modelo
    • Prose dispersa
    • Bloques demasiado pequeños para generar beneficio
    • Modelos fuera de la lista permitida
  • El alcance predeterminado es Fable 5 y GPT 5.6
  • Opus 4.8 y GPT 5.5 tienen peor desempeño leyendo contenido de imagen, por lo que deben activarse explícitamente desde el dashboard o con PXPIPE_MODELS
  • PXPIPE_MODELS=off desactiva la conversión a imágenes
  • En la ruta de GPT, las definiciones de herramientas se mantienen como JSON nativo y no se usan marcadores cache_control de Anthropic

Cómo calcula los costos

  • La tasa de ahorro destacada se basa en el cobro total, no solo en el slice de entrada
  • En una snapshot de 13,709 solicitudes, US$100 bajaron a unos US$41, calculado como 59% de ahorro
  • Luego, en un trace de 8,904 solicitudes comprimidas, se midió cerca de 70%
  • Si se miran solo las solicitudes comprimidas, está en el rango de 72~74%, pero el README no lo usa como titular
  • Para cada POST a /v1/messages, ejecuta en paralelo un count_tokens contrafactual gratuito sobre el cuerpo original sin comprimir
  • El uso realmente facturado se lee del bloque usage de la respuesta de Anthropic
  • El uso original y el real se registran en la misma fila de ~/.pxpipe/events.jsonl, para evitar confusores por turn-count o variación run-to-run
  • La conversión a dólares usa las proporciones de precio de lista de Fable 5
    • input ×1.0
    • cache write ×1.25
    • cache read ×0.1
    • output ×5
  • Los precios de caché se aplican igual en ambos lados, por lo que el descuento de caché no se cuenta dos veces como ahorro

Uso como librería

import { renderTextToPngs, transformAnthropicMessages } from "pxpipe";

const imgs = await renderTextToPngs(toolResultText);            // RenderedImage[]
const { body, applied, info } = await transformAnthropicMessages({
  body: requestBytes,
  model: "claude-fable-5",
});
  • También puede usarse como librería sin el proxy
  • options.keepSharp(block) fija un bloque específico como texto
  • options.emitRecoverable devuelve el original de un bloque convertido en imagen
  • El runtime es Pure JS y soporta Node y edge/Workers
  • @napi-rs/canvas solo se usa en build time
  • La API completa está en src/core/index.ts

Fallas reales y límites

  • Durante varias semanas de uso diario, hubo un caso en que recordó con seguridad pero de forma incorrecta el nombre de una persona desde un historial de chat convertido en imagen
  • Las sesiones de coding toleran este modo de falla porque vuelven a leer los archivos antes de editar, pero el recuerdo en chat puro no tiene esa misma verificación
  • En la legibility audit se mide la recuperación exacta de cadenas desde páginas renderizadas
    • La lectura a ciegas de identifiers densos llegó hasta 63%
    • Todos los misses fueron predichos por una matriz de confusabilidad de glifos
    • Se aplicó una mitigación que limita la geometría de página para ajustarse al resample cap de la API
    • Identifiers exactos como SHA y números se incluyen también como texto
  • También se explicitan limitaciones
    • La recuperación verbatim basada en imágenes es poco confiable
    • Las solicitudes grandes agregan latencia de codificación PNG antes del envío
    • ASCII/Latin-1 está bien probado
    • CJK funciona, pero se maneja de forma conservadora

Desarrollo y roadmap

pnpm install && pnpm test
pnpm run build                # regenerates dist/
  • Los comandos de desarrollo consisten en instalación, pruebas y build
  • La licencia es MIT
  • El roadmap se presenta solo como hipótesis, y no debe tratarse como claim si no incluye cifras y tamaño de muestra
    • Renderizado de glifos más nítido
    • Si el bulk convertido en imagen puede ampliar cerca de 2× el contexto efectivo dentro de la misma ventana de 1M
    • Si un active context más pequeño mejora la precisión en tareas largas

Lecturas relacionadas

1 comentarios

 
GN⁺ 5 시간 전
Opiniones de Hacker News

  • Por lo que veo con Gemini, al procesar PDFs primero hace OCR, luego pasa el texto y las imágenes juntos al modelo, y tengo entendido que no cobra por los tokens de texto.
    Si el backend de Claude está haciendo lo mismo, este hack se parece más a una falla en el esquema de cobro por tokens, y si Claude se comporta como Gemini, es muy probable que lo bloqueen más adelante.

    • Este punto es realmente interesante. Al principio pensé: “de todos modos, internamente eso algún día se convertirá en tokens de texto, así que no hay forma de que el costo real de ejecución sea más barato para Claude”.
      Pero en el comentario de abajo se menciona que DeepSeek mejoró mucho la tasa de compresión con tokens visuales: https://news.ycombinator.com/item?id=48777848
      No entiendo todos los detalles técnicos internos, así que todavía no me queda claro cómo la ruta de OCR podría traducirse en una reducción del consumo total de energía o del costo computacional.
    • No necesariamente. Hay que ver el paper DeepSeek-OCR: Contexts Optical Compression: https://arxiv.org/abs/2510.18234
      Una forma de pasar imágenes a un LLM es dividir la imagen en mosaicos, pasar esos mosaicos por una red neuronal de codificador de visión para generar tokens visuales y luego ingresarlos al LLM como si fueran tokens de texto. Obviamente, se entrena al codificador de visión y al LLM para que se entiendan entre sí. A este enfoque se le llama modelo OCR de extremo a extremo.
      Una vez que tienes un modelo entrenado así, puedes aumentar o reducir el tamaño de la imagen del documento para cambiar la cantidad de tokens visuales usados para representar el mismo documento de texto, y también puedes ajustar parámetros como el tamaño de los parches o la complejidad del codificador de visión.
      Los resultados fueron bastante buenos y, en algunas pruebas, redujeron los tokens de entrada en un 90% manteniendo el 97% del rendimiento de salida.
    • Claude Science tiene una herramienta para extraer PDFs, pero no sé bien si realmente hace OCR.

  • El año pasado probé lo mismo con modelos de OpenAI y, en ese momento, servía para reducir los tokens del prompt, pero requería muchos más tokens de completado, así que al final salía más caro y más lento.
    https://pagewatch.ai/blog/post/llm-text-as-image-tokens/

  • Ah, me duelen los ojos. Parece un README hecho con vibe coding.

    • Las explicaciones comprimidas por un LLM son muy dolorosas de leer. Es difícil señalar exactamente por qué, pero se nota de inmediato y literalmente requiere el doble de esfuerzo entenderlas.
      Por ejemplo:

      Honest caveat, visible in the clip: the pxpipe arm answered the count first and needed one follow-up nudge to also print the ledger balance in the requested one-line format; the plain arm followed the format on the first try. Legibility is solved on Fable — single-reply format compliance is the remaining rough edge.
      Si lo relees cuatro veces, más o menos puedes interpolar qué ocurrió, pero la mayor parte es información innecesaria y confusa.
      Todos los modelos escriben así hasta cierto punto, pero Claude parece ser especialmente grave. GPT 5.5 se siente un poco más conciso y como si comprimiera información más valiosa.

    • Cuando alguien comparte algo que hizo y veo un README de vibe coding, lo tomo como una señal fuerte de que esa persona no entiende lo suficiente lo que creó como para explicarlo con autoridad.
      Con IA sí se pueden construir cosas realmente útiles, sobre todo en áreas donde ya tienes experiencia. Pero entonces hay que 1) decir que se usó ayuda de IA y 2) explicar con tus propias palabras qué demonios hiciste. Mejor todavía si puedes hablar de las limitaciones al trabajar con IA.
      Eso genera la confianza de “vale la pena probar lo que hizo esta persona; entiende bien lo que construyó”.
      El 99% de lo que sale hoy es resultado de gente trabajando en áreas que no entiende en absoluto, así que cuando veo un README así, simplemente cierro la pestaña.

  • Esto parece un hack de precios que quema recursos. Si cierran la falla, ¿no tendría que subir el precio del OCR?

    • No es una falla; se parece más a que codificar información como tokens ópticos es mucho más eficiente que hacerlo como texto.
    • No necesariamente. Este método tampoco usa realmente más recursos. Más bien podría estar eliminando una ineficiencia fundamental.
      Si lo piensas, tiene sentido. Los humanos también leemos código palabra por palabra, pero normalmente lo hojeamos y usamos reconocimiento de patrones para entender a grandes rasgos qué hace. Solo nos enfocamos en partes específicas cuando necesitamos responder una pregunta concreta.
      Diría que los humanos también hacemos naturalmente una optimización por atajo similar.

  • Artículo relacionado: https://blog.can.ac/2026/06/10/snapcompact/

  • Hay que tener cuidado con este enfoque. Es muy posible que la razón por la que baja el costo sea que en realidad se está cambiando a otro modelo de menor rendimiento.
    Por fuera puede parecer Fable, pero quizá no lo sea realmente. Entonces estarías haciendo trabajo extra sin necesidad, y tal vez convenga más volver el modelo a opus 4.8.

  • Parece que Oh-My-Pi (OMP.sh) usa imágenes para compresión de contexto. OMP está construido encima del agente de coding Pi.

  • También hay un white paper de DeepSeek sobre esta técnica: https://www.seangoedecke.com/text-tokens-as-image-tokens

  • Hace tiempo vi un tuit de alguien, probablemente Carmack, Geohot o Karpathy, que decía algo como que las imágenes podrían ser una mejor opción.
    Desde entonces he usado imágenes junto con prompts de frases muy simples para decirle al agente qué está pasando, y a veces ni siquiera pongo texto en el prompt.
    El resultado fue muy bueno.
    Aunque esto no es exactamente lo mismo de lo que hablaba Karpathy, esa idea me llevó a un mejor flujo de trabajo.

  • Lo siento, pero esto no tiene sentido. Funciona y es ingenioso, pero claramente es una forma de esquivar una falla de precios.
    Como cuando la recompensa por víboras hizo que la gente empezara a criarlas, esto aprovecha y fomenta el desperdicio.
    En última instancia, creo que la responsabilidad es del mal esquema de precios de Anthropic, que hizo posible este arbitraje. Pero hasta que lo arreglen, es desagradable que llegue gente a explotarlo y que se genere todavía más basura digital totalmente innecesaria.