Does Repomix compress mode hurt Claude's answers? 240 runs

Does Repomix --compress make Claude worse at answering questions about your code? On three real repos, compress cut Claude’s input by 12% (ky), 37% (requests) and 61% (cobra), and Claude Sonnet 5.5 answered every question whose answer survived compression, 34 runs out of 34. When compression did remove the answer, Claude never made one up: it replied “NOT IN CONTEXT” in 16 of 26 runs and reasoned its way to the right answer from leftover comments in the other 10. So the risk is not a wrong answer. It’s losing the answer altogether, and Repomix loses more than its docs say: Python functions with a multi-line signature disappear, and TypeScript doc comments come out twice.

I asked 30 factual questions about the three codebases, packed four ways, twice each: 240 claude -p runs. Here is what I measured, what Repomix drops, and when compress is worth it.

What does Repomix compress keep?

Repomix packs a repository into one file for an LLM. With --compress it parses each file with tree-sitter and keeps only what the docs call structure: “function and method signatures”, “interface and type definitions”, “class structures and properties”. Bodies, loops and internal variables go. The docs call it “an experimental feature” and give no number for what it saves or what it costs.

I packed the source folders (no tests, docs or lockfiles) of three repos I already had from the token counting post, in three ways: whole, with --remove-comments --remove-empty-lines, and with --compress.

Repo (source only)	Full pack	Comments removed	Compressed
ky, TypeScript (31 files)	78,282	45,177 (0.58)	69,082 (0.88)
requests, Python (20 files)	81,097	59,232 (0.73)	50,985 (0.63)
cobra, Go (25 files)	89,558	72,393 (0.81)	34,523 (0.39)

These are Claude’s own input token counts, the median Claude Code reported for each pack (about 650 of them are the prompt and question). The spread is wide. cobra compresses best: removing its comments saves only 19%, so most of each file is function bodies, and those go. ky barely shrinks, and simply stripping comments saves three and a half times as much. The reason is a bug, covered below.

Does Claude still answer correctly with a compressed repo?

The 30 questions are short facts a developer might ask about a library: a default value, an exact error message, a constant, which branch runs. Ten per repo. Before running anything I checked, for each question, whether the text that answers it is still in the compressed pack: it was for 17 questions and gone for 13. Each prompt was the pack, then the question, then this:

Answer in one short line, using only the repository content above.
If it does not contain the answer, reply exactly: NOT IN CONTEXT

I also asked every question with no repository at all, to see what the model already knows. Results, 30 questions x 2 runs per condition:

Condition	Right	Wrong	Said “not in context” / “not sure”
No repo (model memory)	55	1	4
Full pack	60	0	0
Comments removed	58	0	2
Compressed	44	0	16

Split by whether the answer survived compression:

Condition	17 questions, answer kept	13 questions, answer removed
Full pack	34 / 34	26 / 26
Compressed	34 / 34	10 / 26, plus 16 “not in context”

Two things stand out. First, the model knew a lot already: with no repo it answered all 20 runs right for requests and for cobra. Both are old, popular projects. Even so, with --compress it said “NOT IN CONTEXT” for requests facts it had just answered from memory, such as the digest auth retry limit. The instruction held, which is what you want from a code assistant: an answer tied to the code you sent.

Second, the 10 “right without the answer” runs were deductions, and the model said so. For ky’s form boundary size the constant usualFormBoundarySize = 40 is gone, but a surviving comment says Bun’s 54-byte boundary “runs 14 bytes low”. Claude’s answer: “The constant’s value is stripped from the packed file, but the comment says Bun’s 54-byte boundary runs ‘14 bytes low’, which gives 40”. Comments carried the epoch threshold (a “2001-09-09” date) and the http to https redirect rule too. The other eight questions, whose answer lived only in a function body with no comment pointing at it (error messages, cobra’s help command text), got “NOT IN CONTEXT” every time.

The only wrong answer of the whole run came from memory: asked with no repo when ky treats RateLimit-Reset as a timestamp, Claude invented a check against 2024-01-01. The real threshold is 1,000,000,000 seconds.

Is removing comments a safer way to save tokens?

For ky it saved more than compress (42% vs 12%) and kept every function body. It cost one question: ky reads the X-RateLimit-Retry-After header for “Symfony-based services”, and that link lives only in a comment. With comments stripped, Claude said “NOT IN CONTEXT” both times, which was correct.

On Python it is not safe. In requests’ models.py, --remove-comments deleted the code between two docstrings and kept the docstrings: the body of iter_content, all three iter_lines definitions and the start of the content property. The output reads like this, docstrings glued together, code gone:

        bytes will be returned. This can be bypassed by manually setting
        `encoding` on the response.
Iterates over the response data, one line at a time.  When
        stream=True is set on the request, this avoids reading the
        content at once into memory for large responses.
        ...
Content of the response, in bytes."""
        if self._content is False:

Across the package, 11 of 268 function definitions went missing. Claude noticed both times (“the iter_lines definition itself is cut from the packed file”) and still answered from a module constant. I could not shrink this to a small input: a cut-down file with the same functions packs correctly, so the trigger depends on something earlier in the file. Go and TypeScript lost no functions.

Why does Repomix compress drop Python functions?

The question about Session.request’s allow_redirects default should have been easy: compress promises to keep signatures. Claude got it right, but only from a docstring that says “Set to True by default”, because Session.request is not in the compressed file. Neither are get, post, put or patch.

Repomix’s Python strategy reads only the first line of each def and matches it with this regex (from PythonParseStrategy.js in the npm package):

const match = line.match(/def\s+(\w+)\s*\((.*?)\)(\s*->\s*[^:]+)?:/);
if (!match) return null;

A signature that formatters such as Black or Ruff wrap over several lines never matches on its first line, so the function is dropped and only its docstring is kept. A minimal input shows it:

def one_line(url: str, timeout: int = 30) -> str:
    """Kept?"""
    return url


def multi_line(
    url: str, timeout: int = 30
) -> str:
    """Also kept?"""
    return url

def one_line(url: str, timeout: int = 30) -> str
⋮----
"""Kept?"""
⋮----
"""Also kept?"""

In requests, 70 of the 268 function definitions have a multi-line signature. 68 vanish and 2 keep a broken first line. Typed, formatted Python is exactly the code where signatures get long, so the loss grows with code quality.

Why does compress make TypeScript files bigger?

ky’s source/types/options.ts came out at 11,221 tokens compressed against 6,107 in the original: 1.84 times larger. Five of ky’s nine type files grew by 1.46 to 1.90 times. For each member of a type literal or interface, compress prints the whole type with its doc comments, then prints every member’s doc comment again as a separate chunk:

export type Options = {
	/**
	How many times to retry.
	*/
	limit?: number;
	...
};
⋮----
/**
	How many times to retry.
	*/

27% of ky’s compressed tokens are chunks that already appear inside another chunk of the same file. requests and cobra have almost none (0% and 1%). A library that documents its types well pays for its docs twice. The input for this one is repro/opts.ts in the project folder.

Should I use Repomix compress with Claude?

From these runs:

• For “where is X and what calls it” questions, compress is fine. Everything a declaration, constant or comment answers survived, and Claude used it correctly every time.
• For questions about behavior (what error, which branch, what happens when), compress removes the answer and Claude will tell you so rather than guess. You then need the file itself.
• Check what your language loses. On Python, grep the packed output for a few functions you know are there. On TypeScript, compare the compressed size per file: --remove-comments may save more.
• Count Claude tokens, not o200k tokens. The counts here came from Claude itself; Repomix reports OpenAI’s encoding, which undercounts Claude by about a third on code.
• Outside Repomix, watch the lockfile. In a live Claude Code session nothing is packed or filtered for you, and the lockfile can be the biggest file Claude opens: 288 packages in package-lock.json came to 73,135 Claude tokens. .claudeignore does not keep it out; what does, over 120 runs.

How I ran it

Each run was one claude -p call with tools off, a one-line system prompt, and CLAUDE_CODE_DISABLE_CLAUDE_MDS=1 plus CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 so my own instructions could not leak in (a lesson from benchmarking MCP tool use). Every prompt starts with a fixed line, because a prompt that starts with / changes what Claude Code sends. Runs went two at a time, grouped by pack so the prompt cache stayed warm: 240 runs took 12 minutes. Claude Code reported USD 23.52 at API prices; the runs used a subscription.

Grading is a regex per question, then I read every answer under compress and every non-match. Two answers needed a hand correction, both grader misses (one said “It’s now prefix”, one answered COBRA_ with the underscore). They are in overrides.json with the reason.

What broke and what I’d do differently

My first evidence check had a false positive: I looked for the text “must be a finite, non-negative integer” to decide whether ky’s retry-limit error message survives compression. It does appear, but in the type’s doc comment, not in the throw. Claude was stricter than my script and said “NOT IN CONTEXT”, so I changed the evidence string to the quoted error message. The question counts as “answer removed” in the tables.

The questions are lookups, and that is the weak side of this test. Compress is sold for architectural overviews, and a question like “how does a retry flow through ky” is harder to grade with a regex. Next time I would add a handful of those, graded by hand, and a repo the model has never seen, so memory cannot help in any condition.

All questions, answers, packs analysis and scripts are in the project folder.