Hello,
Problem:
On the first read of any file, view_file forces loading the first 800 lines regardless of the StartLine/EndLine passed. We have tooling that tells the agent exactly which line range to read before it opens the file, so it can read lean and targeted. The forced 800-line first read overrides that — the agent asks for lines 80–110 and gets 1–800 anyway. On large files this loads hundreds of irrelevant lines into context on every first access, which defeats the whole point of knowing the range up front and burns tokens for no benefit.
Request:
(a) honor StartLine/EndLine on first read when they are explicitly provided, or
(b) expose the 800-line default as a config setting so it can be lowered or disabled per workspace/session.
The current behavior makes targeted reads impossible exactly when they matter most : the first time the agent touches a large file.
Thanks
Follow-up with measured data to quantify the cost of the forced 800-line first-read.
I instrumented a production conversation (2,422 steps, 8-day build session) by extracting token counts from gen_metadata protobuf entries in the conversation SQLite DB. Here’s what VIEW_FILE actually costs:
Uncached Input Decomposition (top 5 of 18 message types)
| Message Type |
Count |
New Tokens |
% of Uncached Input |
Avg Tokens/Call |
| PLANNER_RESPONSE |
2,456 |
1,157,507 |
35.2% |
471 |
| VIEW_FILE |
576 |
1,071,523 |
32.6% |
1,860 |
| CODE_ACTION |
434 |
210,062 |
6.4% |
484 |
| RUN_COMMAND |
745 |
196,953 |
6.0% |
264 |
| CHECKPOINT |
62 |
184,613 |
5.6% |
2,978 |
VIEW_FILE is the #2 uncached input contributor at 32.6% — 1.07M tokens across 576 calls, averaging 1,860 tokens per call.
For context: uncached input is 60.6% of total session cost (44M tokens at full price vs 276M cached at ~10%). So VIEW_FILE alone accounts for ~19.8% of total session cost.
Why the first-read override matters
Our tooling tells the agent exactly which lines to read before it opens the file. A typical investigation read needs 30-50 lines. But the forced 800-line first-read means:
- Agent requests
StartLine: 80, EndLine: 110 → gets 800 lines (lines 1-800)
- That’s 1,860 tokens instead of ~140 tokens → 13× overhead on the first access
- Investigation reads are estimated at ~60% of VIEW_FILE calls (345 of 576)
Estimated savings
If the first-read honored StartLine/EndLine when explicitly provided:
- 345 investigation reads × (1,860 - 465 avg targeted) = ~481K tokens saved per session
- That’s ~14.6% of uncached input eliminated, or ~8.8% of total session cost
- No behavior change for reads without StartLine/EndLine (full 800-line default preserved)
Measurement methodology
- Token counts from
gen_metadata protobuf field f4.2 (non-cached input tokens)
- Field validated:
f4.2 < f4.5 on 2,216/2,216 cache hits — arithmetically impossible if f4.2 were total input, proving it’s the uncached portion
f4.5 = cached_content_token_count (confirmed via Gemini API usage_metadata docs)- Decomposition: content-hash diff between consecutive steps to identify new messages, aggregated by type
The data is from a single long conversation, but it’s representative of our typical build sessions (100-500 agent turns, ).
This is the lowest-hanging fruit in our token budget ,a behavioral change that saves ~15% of uncached input with zero risk to existing behavior.
Found a solution through hook to honor the line properly.