The 60% Cost Cut That Broke My Assumptions About AI Coding

I kept dismissing the idea as obviously inefficient until my API bills started shrinking. Three months ago, I stumbled across Fable's approach to AI code analysis: convert code to images, run OCR, then feed the text to language models. My first reaction was immediate skepticism—why would anyone add two extra steps when you can send code directly as text?

The claim was substantial cost reduction. That number bothered me enough that I had to test it myself.

The Setup That Seemed Backwards

I built a simple pipeline to mirror what Fable was doing. Take Python functions, render them as PNG files with consistent formatting, run them through Tesseract OCR, then send the extracted text to Claude for analysis. Every instinct I had as a developer screamed that this was adding unnecessary complexity.

The first week's results didn't make sense. My token usage dropped by nearly half, but the AI's code analysis remained just as accurate—sometimes more so. I kept double-checking my measurements, convinced I'd made an error somewhere.

I tracked three specific metrics:

• Token count per function analyzed
• API cost per analysis session
• Processing accuracy on code smell detection

The visual approach consistently used 40-50% fewer tokens than sending the same code as plain text. The cost savings were real.

Where the Efficiency Actually Came From

The token compression happened in ways I hadn't anticipated. When Claude processes code as images, the OCR step strips out inconsistent whitespace and normalizes formatting. What I initially saw as data loss turned out to be noise reduction.

More surprising was how the visual processing seemed to change the AI's attention patterns. When analyzing the same buggy function through both approaches, the text-first method would sometimes get caught in verbose explanations of syntax. The visual approach more consistently identified the actual logical errors.

I tested this on a function with a subtle off-by-one error in a loop condition. The text analysis gave me three paragraphs about coding style and briefly mentioned the logic issue. The visual analysis went straight to the loop problem and suggested the fix.

The Cases Where It Failed Completely

The approach falls apart predictably. Code with unusual formatting breaks OCR reliability. Functions longer than what fits cleanly in a single image get truncated or split awkwardly. Anything with complex Unicode characters becomes garbled.

I also found the visual method struggles with context that spans multiple files. When the AI needs to understand how functions interact across a codebase, the image-by-image processing creates artificial boundaries.

But within its constraints—well-formatted, self-contained functions—the visual approach kept outperforming my expectations.

What This Suggests About Tokenization

I started wondering if our text-first approach optimizes for human language patterns rather than code structure. Current tokenization treats code like prose, breaking it into linguistic chunks. But code has visual structure that might matter more than we realize—indentation, alignment, the spatial relationship between elements.

When I look at code, I'm not just reading left-to-right like text. I'm scanning vertically for patterns, using whitespace as semantic information. Maybe the visual processing preserves something that gets lost when code is tokenized as sequential text.

The cost savings suggest that converting code to images and back might actually be closer to how AI models want to process structured information, even if it seems roundabout to us.

The Broader Pattern I Keep Noticing

This experiment sits in a category of approaches that feel obviously wrong but keep producing better results. Like how training larger models sometimes makes them more efficient, or how adding randomness can improve optimization.

I'm starting to suspect we build AI tools around what makes sense to developers rather than what works best for AI systems. We assume that because direct text input is simpler for us to implement, it's also optimal for the model.

Three months in, I'm still not sure if I've discovered a genuinely superior approach or just found an edge case that happens to work with current models. But watching my API costs drop while analysis quality stayed steady has me questioning other assumptions about AI efficiency.