All writing

September 29, 2025

How Bad Code Formatting Eats Up Your LLM Tokens

Large Language Models process code as tokens, not visual formatting. Poor structure directly impacts costs, processing speed, and context window limits.

LLM Developer Experience Tooling

Large Language Models don’t read code the way we do. They process it as tokens — and the formatting choices we make every day have a direct, measurable effect on how many tokens get consumed.

Why formatting matters

Messy formatting creates token bloat through a handful of common patterns:

  • Excessive spaces and newlines
  • Verbose variable naming conventions
  • Lengthy, redundant comments
  • Duplicated code blocks instead of reusable functions

These aren’t just style complaints. Each unnecessary character is a token the model has to process, pay for, and fit inside a finite context window.

The numbers

Consider two ways of writing the same intent. A poorly formatted version with verbose variable names:

const user_is_authenticated = checkIfUserIsAuthenticated(theUserNameVariable);

Against a clean, concise version:

const isAuth = checkAuth(user.name);

Tokenize both. The verbose version costs 44 tokens. The clean version costs 17 tokens. That’s a 61% reduction for the same logic — just from naming and whitespace.

Scale that across a codebase you’re feeding into a prompt, and the difference becomes significant: higher API costs, slower responses, and less room for the model to focus on what actually matters.

Why structural inefficiency is worse than style

Formatting is the visible part. The deeper cost comes from structural problems:

  • Duplicated logic that forces the model to process the same pattern multiple times
  • Missing helper functions that make context larger than it needs to be
  • Boilerplate that fills tokens without adding meaning

When the model has to wade through noise, the useful signal gets diluted. You pay more and get less focused output.

What to do about it

The fixes aren’t complicated:

  • Run a formatter. Prettier, ESLint, or Biome will handle whitespace and style consistency without manual effort.
  • Refactor for reusability. A shared helper is shorter than two copies of the same logic.
  • Use concise but meaningful names. isAuth beats user_is_authenticated; id beats theCurrentUserId.
  • Share only the relevant slice. Don’t paste an entire file when the model needs one function.
  • Write comments that add context, not noise. A comment restating what the next line does wastes tokens. A comment explaining why earns its space.

The OpenAI Tokenizer at platform.openai.com/tokenizer is a quick way to sanity-check your own code before sending it to a model.


Token cost is a feedback loop: the cleaner your code, the cheaper and sharper the model’s response. Good formatting was already worth doing — now it has a price tag on it.