❯ what did eat up the context?
● The main culprit is Messages at 78.9k (39.5%). Breaking down what ate
it:
1. Full raw file reads (~35–40k of that 78.9k)
These were each read completely to find the exact lines to edit. The
fix: use compress_bodies: true on read_file/get_editing_context — it
elides function bodies down to ~30–40% of original tokens. For
something like some_file1.cpp (16k) that would have saved ~10k tokens
alone.
2. The plan file (~3k) — loaded by the session hook at conversation
start.
3. Edit failures and retries (~5k) — the CRLF multi-line match
failures each returned an error + the tool call overhead, then the
retry. Five failed attempts × ~500 tokens each.
4. smart_context response (~2.3k) — returned mostly autovcpkg
functions which weren't relevant; a more targeted call with path would have been cheaper.
The fix for next time: on a "replace N call sites" task like this, use
search_text first to locate each site (cheap), then edit by
single-line unique matches — no full file reads needed at all.
✻ Cogitated for 21s
❯ didn't you use gortex for file reads?
● Yes, I did use Gortex's read_file for everything — but I made a key
mistake: I didn't pass compress_bodies: true on the large C++ files.
The tool supports replacing function bodies with { /* N lines elided
*/ } stubs, keeping only signatures and structure. For
some_file2.cpp (20k bytes) that would have dropped it to ~6-8k. I
read it in full, even though I only needed to find two lines
(std::cerr << ...).
The more efficient pattern for this task would have been:
1. search_text with query: "std::cerr" / "std::cout" — gets exact file
+ line numbers for every site in one call, ~200 tokens total
2. edit_file directly on each match — no reads needed at all
Instead I read 6 full files (~80k bytes worth of content) just to
confirm what I already knew from the plan. The plan listed every call
site explicitly — I didn't need to re-read anything.
✻ Churned for 10s
❯ looking at the current gortex setup, including the plugin, can you
pinpoint why you didn't use search_text and compress_bodies? How can
we fix that?
● Two separate root causes:
Why search_text wasn't used:
The plan file had every call site listed explicitly. I treated that as
a reason to skip search and go straight to "verify by reading the
file" — a habit from the non-Gortex Read → Edit workflow. The
CLAUDE.md table says to use search_text instead of grep, but it
doesn't say "use it even when you think you already know the
location." There was no forcing function.
Why compress_bodies wasn't used:
The read_file schema does document it, but nothing required it. I
defaulted to the simplest call. The PreToolUse hook blocks
Read/Grep/Glob on indexed files, but once you're inside a Gortex tool,
there's no equivalent guard on how you call it.
---
The fix: a PreToolUse hook on mcp__gortex__read_file
You can add a hook in .claude/settings.json that fires when read_file
is called without compress_bodies: true, injecting a reminder:
{
"hooks": {
"PreToolUse": [
{
"matcher": "mcp__gortex__read_file",
"hooks": [{
"type": "command",
"command": "node -e \"const
i=JSON.parse(require('fs').readFileSync('/dev/stdin','utf8'));
if(!i.compress_bodies) { process.stderr.write('[Gortex] read_file
called without compress_bodies:true — did you mean to read the full
file? Consider search_text to locate sites, or add
compress_bodies:true.\\n'); }\""
}]
}
]
}
}
And/or a CLAUDE.md addition — promote it from a table row to a
MANDATORY callout:
## MANDATORY: Gortex read discipline
- Before calling `read_file` or `get_editing_context`, ask: do I need
full bodies?
- If you're **locating call sites**: use `search_text` — no read
needed.
- If you're **reading to edit**: use `compress_bodies: true` —
always.
- Never read a full file just to confirm what a plan already told you.
The hook catches the lazy case at tool-call time; the CLAUDE.md
addition makes the rule salient before the decision is made. Together
they close both gaps.
Describe the bug
Using Claude Code (Sonnet 4.6) with gortex setup reads whole files and uses up context during implementation when a plan is provided (generated from /plan mode)
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Gortex will block that and force search_text instead
Environment:
gortex version]Additional context
Chatting with claude about the issue: