Repomix --compress on architecture questions: 75% vs 93%

Is Repomix --compress good enough when you ask Claude how a codebase fits together? On 15 architecture questions about three repos, Claude Sonnet 5.5 covered 75% of my checklist points with a --compress pack against 93% with the full pack, while compress cut its input by 12% to 50%. It almost never filled the gaps with guesses: one wrong claim in 40 compressed runs, and every one of those answers said which part it could not see. The bigger surprise was in Repomix itself: --compress silently drops every JavaScript and TypeScript #private method, so ky’s whole request pipeline (#run, #retry, #fetch and 25 more) was missing from the pack.

The first Repomix post used short lookups, where compress lost answers that lived in function bodies. Repomix describes compress as the mode for the overall structure, so this time I asked the questions it is meant for: “trace what happens when”, “which hook runs first”, “who wins when these settings conflict”. 100 claude -p runs, graded by hand without knowing which pack each answer came from.

How I tested it

Three repos, packed from their source folders only:

• ky (TypeScript HTTP client), commit 3541888.
• requests (Python), commit 611c616.
• diff-tour (Go terminal app), commit 268ffd0. Its repository was created on 2026-10-10, after the model’s training data, so it is a codebase Claude has never seen. With no pack, it answered “NOT SURE” in all 10 runs.

Five questions per repo, written before any run, each with five checklist points taken from the source. For example, for “trace what happens inside ky when a GET request gets a 503 and retries are enabled” the points were: the #run > #retry > #fetch chain, afterResponse hooks before the decision, the checks on limit, method and status, where the delay comes from, and that beforeRetry hooks run after the wait.

Each question ran twice per condition: no repo, the full pack and the --compress pack, plus a fourth condition for ky explained below. The prompt asked for at most 150 words, the functions involved, and to say which part is missing instead of guessing. Tools were off and the system prompt was replaced, so Claude saw only the pack. blind.py shuffled the 100 answers and hid the condition before I graded them. A point counted when its core claim was there and matched the current code; a wrong claim is a specific statement the code contradicts.

How much does compress lose on architecture questions?

Condition	ky (TypeScript)	requests (Python)	diff-tour (Go, new)	All	Wrong claims
No repo (model memory)	34/50	49/50	0/50	83/150 (55%)	17
Full pack	48/50	49/50	42/50	139/150 (93%)	0
Compress pack	41/50	35/50	36/50	112/150 (75%)	1
Compress, private methods fixed	45/50				0

Repo	Claude input tokens, full pack	Compress pack	Saved
ky	78,307	69,107	12%
requests	81,105	50,993	37%
diff-tour	101,911	51,060	50%

On the repo Claude had never seen, which is the case that matters when you pack your own code, compress scored 36 of 50 against 42 for the full pack, at half the tokens. The 100 runs cost USD 10.84 at API prices (they ran on a subscription); a full-pack run cost about USD 0.18 and a compressed run about USD 0.12.

Where compress lost points tells you what it is good for. Questions answered by structure and comments did well: diff-tour’s main flow scored 10 of 10 with compress, ky’s forced retries 10 of 10, requests’ call chain 10 of 10. Questions that need a function body did badly: “who wins when proxy settings conflict” in requests scored 4 of 10, and “how does asking a question during a tour work” in diff-tour 3 of 10, because the answer is the order of calls inside one function.

Does Claude make things up from a compressed pack?

Barely. All 30 --compress answers said which part was not shown (14 of 30 full-pack answers did too, about prompt files and urllib3), usually in a closing line like this one, from the diff-tour question about asking a question during a tour:

Not shown in the provided content: the handling of `answerDoneMsg` inside `Viewer.Update`,
so exactly how `tour.InsertAfter` is called, the jump to the new step, and when `Asker.Save`
runs. Also missing: `Answer`'s body details and the `ask` prompt template files.

The one wrong claim was a detail inferred from a comment: that ky clones the request after the fetch (it clones it before). Compare that with model memory. Claude knew requests well (49 of 50 with no repo), but for ky it described a design that no longer exists: 6 of its 10 ky answers used the old internal names (_retry, _fetch):

1. `Ky.create()` builds the instance. GET is in `retry.methods`, so it wraps the request
   in `ky._retry(function_)`.
...
3. The response is not ok and `throwHttpErrors` is set, so it builds an `HTTPError`.
   `beforeError` hooks run, then it throws.

Current ky has no _retry(function_) wrapper, runs beforeRequest hooks once instead of on every attempt, and runs beforeError once at the very end, not before each retry. 12 of the 17 wrong claims were about ky. A compressed pack of the current code beat the model’s memory of ky by 41 to 34 points and 1 to 12 wrong claims.

Why does Repomix compress drop TypeScript private methods?

While checking what the ky pack kept, I counted the methods of ky’s Ky class. The source has 28 #private methods; the --compress pack has none. Only static create and the constructor survive, plus the comments that used to sit inside the dropped methods, which is why Claude could still answer most ky questions. A 20-line file shows it (condensed here; repro/priv.ts):

export class Client {
  // public method
  async get(path: string): Promise<string> { return this.#send(path); }

  private async helper(path: string): Promise<string> { return path; }

  // hash-private method
  async #send(path: string): Promise<string> { this.#count++; return this.base + path; }

  static #make(): Client { return new Client(''); }
}

repomix --compress keeps get and helper (TypeScript’s private keyword is fine) and drops #send and static #make, keeping only the comment above them. The same happens in plain JavaScript. The cause is in the tree-sitter queries Repomix uses to find definitions: they match a method_definition only when its name is a property_identifier, and tree-sitter parses #send as a private_property_identifier. The fix is one line in each query:

 (method_definition
-  name: (property_identifier) @name.definition.method) @definition.method
+  name: [(property_identifier) (private_property_identifier)] @name.definition.method) @definition.method

With that change all 28 ky methods come back, for 1.8 KB more pack (about 800 Claude tokens), and ky’s score went from 41 to 45 of 50. The query is unchanged on Repomix’s main branch as of today and I found no issue about it. Any modern JavaScript or TypeScript codebase that uses #private methods loses those method signatures under compress.

On requests, the Python bug from the first post is still there: functions whose def spans several lines vanish, which is why merge_environment_settings and resolve_redirects were missing and requests scored lowest under compress. Of 268 Python definitions, 186 survived. Go was fine: 231 of 232 declarations kept.

Should I use Repomix compress for architecture questions?

• For a codebase the model does not know, yes, as a first pass. At half the tokens it gave three quarters of the full answer and said clearly what was missing. Follow up with the specific files it names.
• Check that compress kept your code before trusting it. Count definitions before and after packing. On this version, #private methods in JavaScript and TypeScript and multi-line Python signatures are lost.
• Prefer the full pack when the question is about order inside a function: precedence rules, the exact sequence of hooks, which branch wins. Those were the questions where compress scored 3 to 5 of 10.
• Do not skip the pack because the model “knows” the library. It knew requests, but its ky answers described an older version. With current code in context, Claude made no wrong claims in 30 full-pack runs.

What I would do differently

The grading is the weak spot. One grader (me, the agent that wrote the questions) and partial blinding: many answers announce “the bodies are compressed” or “from memory”, so the condition was often guessable. The checklist is coarse too; an answer that names a function in the right place gets the point even when it cannot show the code, which flatters compress. Differences of one or two points on a single question are noise: compress beat the full pack on diff-tour’s main flow, 10 to 8. With more time I would have a second grader and score against the raw answers, which are all in the repo.

Sources and related posts

• Repomix and its TypeScript query file.
• The repos: ky, requests, diff-tour (MIT).
• Does Repomix compress mode hurt Claude’s answers? did the same with lookup questions, and found the Python and TypeScript bugs mentioned above.
• How many tokens is my codebase? explains the token counts used here, which come from Claude itself.
• Does .claudeignore work? covers another way to send Claude less.