Does telling AI to skip code indentation actually save tokens?

This is the first post in a series I plan to keep going here: quick takes on studies, tools and news that catch my attention during the week. This was the first topic that grabbed my attention this time, so let's get straight to it.

I saw a video on X covering a study claiming that instructing an AI to skip indentation, whitespace and newlines in code saves a solid amount of tokens. I tracked down the original paper, The Hidden Cost of Readability: How Code Formatting Silently Consumes Your LLM Budget, from researchers at Monash University and Singapore Management University.

What they tested

The authors tested ten AI models (including GPT, Claude and Gemini) on a task common to every IDE coding assistant: completing a code snippet with the middle section missing. They did this across four languages (Java, Python, C++ and C#), comparing normally formatted code (indented, spaced, the way any editor does automatically) against "squeezed" code (no indentation, no extra whitespace, no line breaks) while keeping exactly the same meaning for the compiler.

The actual numbers

In Java, the language that benefits the most, the average input token reduction was 34.9%, with one model (DeepSeek) reaching 42% in specific cases. That's where the "almost 40%" I'd heard came from: real, but it's the ceiling, not the average. The overall average, across all languages and models, was 24.5%. Python barely gains anything (6.5%), because indentation and newlines are part of its syntax and can't be stripped without breaking the code.

And the most important part: answer quality barely changes. No setting dropped more than 4.2%, and for some models results even improved without formatting.

The detail that changes the whole math

Here's what the video left out: this token savings is on input only. What the model generates back still comes out formatted, in whatever style it picked up during training. Output reduction averages around 2.5%, basically negligible.

To also save on output, the authors tested two approaches: explicitly instructing the model to generate unformatted code, or fine-tuning on a handful of examples. Prompting worked well for GPT-4o (27.2% output reduction while keeping quality), but broke Gemini-1.5: the model stripped spaces the syntax actually requires, producing invalid code like staticbool instead of static bool, and its accuracy on C++ dropped from 67.2% to 11.1%. Fine-tuning with just 50 samples worked better and without that risk, cutting output by up to 35.9% for Gemini-1.5 and 24.8% for GPT.

What this means in practice

This confirms what I already suspected, with one important correction: you get free, risk-free savings just by stripping formatting from what you send the model: it works cleanly across all ten models tested. But that only solves half the cost. The other half, what the model sends back, needs either a carefully worded prompt (with real risk on weaker models) or fine-tuning.

The authors went beyond just measuring and built a tool that converts in both directions: strips formatting before sending code to the model and restores it for humans to read, verifying the generated code stays exactly equivalent to the original in 100% of test cases, taking about 76ms per file.

My take

Saving on input is essentially free and risk-free, so it makes sense in any pipeline that sends a lot of code to an AI as context. Saving on output takes more care: a poorly worded prompt can break syntax on weaker models, so it's worth measuring before trusting the instruction blindly. For code a human is going to read directly, formatting is still the right call; the token savings don't offset the readability cost.