Skip to content
OpenTrain AIFor AI Companies

The Hidden Cost of Readability: How Code Formatting Silently Consumes Your LLM Budget

Dangfeng Pan, Zhensu Sun, Cenyuan Zhang, David Lo, Xiaoning DuPublished Aug 19, 2025
arXiv PDF
Researcher verdict
Starting point
Use as implementation starting point
Benchmark evidence
Thin evidence
Verify before relying
Time to first repro
A few hours
Fast first run
Risk flags
1
Review before use

Abstract

Domain fit: AI-core · Core AI workload signals detected from paper context and implementation/artifact evidence.

Source code is usually formatted with elements like indentation and newlines to improve readability for human developers. However, these visual aids do not seem to be beneficial for large language models (LLMs) in the same way since the code is processed as a linear sequence of tokens. Furthermore, these additional tokens can lead to increased computational costs and longer response times for LLMs. If such formatting elements are non-essential to LLMs, we can reduce such costs by removing them from the code. To figure out the role played by formatting elements, we conduct a comprehensive empirical study to evaluate the impact of code formatting on LLM performance and efficiency. Through large-scale experiments on Fill-in-the-Middle Code Completion tasks across four programming languages (Java, Python, C++, C\#) and ten LLMs-including both commercial and open-source models-we systematically analyze token count and performance when formatting elements are removed. Key findings indicate that LLMs can maintain performance across formatted code and unformatted code, achieving an average input token reduction of 24.5\% with negligible output token reductions. This makes code format removal a practical optimization strategy for improving LLM efficiency. Further exploration reveals that both prompting and fine-tuning LLMs can lead to significant reductions (up to 36.1\%) in output code length without compromising correctness. To facilitate practical applications, we develop a bidirectional code transformation tool for format processing, which can be seamlessly integrated into existing LLM inference workflows, ensuring both human readability and LLM efficiency.

Results and benchmarks

Freshness tier: cold
Source code is usually formatted with elements like indentation and newlines to improve readability for human developers.
Task Dataset Metric Value Source
Natural language processing Fail Gemini 2.6 paper-derived
Natural language processing Claude pass@1 72.3 paper-derived

Audit each benchmark finding before selecting an implementation path. Evidence refs map to the disclosure below.

Implementation

Best maintained implementation now

Recommended
Confidence: Medium
Reproducibility: Moderate

Local proxy that compresses your LLM API requests so you pay less, with no change to the answers. Trims wasted tokens from prompts, history, tool output, and code before they're sent: -31% input / -74% output, measured live. Any provider, no extra model calls. Also an MCP server and embeddable library (Rust, Python, Ruby, Kotlin, Swift, JS/TS).

257 stars · 23 forks · Last push Oct 20, 2026 · MPL-2.0 license

  • License
  • CI
  • Dependencies
  • Docker

Matched via arXiv identifier search · Strong overlap with paper title keywords · Community adoption signal (257 stars)

Why this implementation
Confidence: medium

fkiene/llmtrim is the best available implementation candidate based on ranking signals, but recommendation confidence is not yet high. CI workflows are present. License is declared (MPL-2.0).

Open fkiene/llmtrim
Reproduction risks
  • Dependency manifest is missing
  • Selected fkiene/llmtrim as the strongest maintained implementation for new work.
  • Includes CI workflow signals.
  • Repository activity is within the last 24 months.

Compare implementation paths

Compare maintenance quality, reproducibility coverage, and evidence confidence before choosing a reproduction baseline.

fkiene/llmtrim
best maintained
Maintenance
Active
Confidence
Medium
Reproducibility
Moderate
Stars
257
Last push
Oct 20, 2026 (9d)

Matched via arXiv identifier search · Strong overlap with paper title keywords

  • Dependency manifest missing
Maintenance
Stale risk
Confidence
Low
Reproducibility
Moderate
Stars
23
Last push
Mar 23, 2026 (221d)

Matched via arXiv identifier search · Partial overlap with paper title keywords

  • No CI pipeline detected
  • Low confidence match
Maintenance
Active
Confidence
Low
Reproducibility
Strong
Stars
9
Last push
Oct 23, 2026 (7d)

Matched via arXiv identifier search

  • No Docker setup
  • Low confidence match

Reproduction readiness

Time to first repro: hours
Last checked: Oct 28, 2026

Major work

No dependency manifest, manual reconstruction required

  • fkiene/llmtrim has no requirements.txt, environment.yml, pyproject.toml, or Dockerfile.
  • You will need to reverse-engineer dependencies from import statements in the source code.
Open fkiene/llmtrim

Repositories and ecosystem

No additional verified repositories beyond the primary recommendation.

Hugging Face artifacts

No direct paper-linked artifacts were found. Showing strongest curated related artifacts for faster exploration.

Datasets

No trustworthy datasets matches right now.

Search datasets on Hugging Face

Spaces

No trustworthy spaces matches right now.

Search spaces on Hugging Face

Research context

Tasks

Natural language processing

Methods

Transformer

Domains

Natural Language Processing, Large Language Models

Evaluation and human feedback data

Open this paper in HFEPX to review benchmark signals, evaluation modes, and human-feedback protocol context.

Open in HFEPX
Explore similar papers

Jump to Paper2Code search queries derived from this paper's research context.