squeezy builds a local knowledge database of your code, so the first model call doesn't start from a blank repository.
how it works
where does an agent's money actually go?
what you pay for besides the change you asked for
01 · understand first Finding the code is billed work
An agent that searches its way to the right file pays for every file it opened on the way there.
02 · don't pay twice The same bytes, bought againInstructions, files, and command output come back turn after turn, and every turn pays full price for them.
03 · right-size turns Everything sent at full sizeThe whole build log goes in, the history only grows, and the strongest model takes a turn that never needed it.
04 · stay in control A number you only read afterwardsSpend you can watch but cannot stop is not control. By the time a total lands, the turn has already been paid for.
prepare locally · then ask the model with focus
the loop
From your question to the model call.
Each step decides what the model will not have to read. The request goes out last.
Broad questions narrow to specific files, symbols, diffs, and command output, not whole directories.
Repeated output becomes receipts, noisy output is shaped, and long sessions are compacted before they get expensive.
The model gets the useful context, and squeezy tracks tokens, cache, tool output, and estimated spend.
understand · narrow · tighten · send
understand first
Understand the code first
Before spending a token, squeezy reads your repository locally and works out which files and lines matter.
squeezy finds the exact declarations, callers, and slices on your machine, then sends the model those instead of entire files.
A local code knowledge database spans 40+ languages and formats: every symbol, definition, caller, and reference. So "who calls this?" is one query, not a dozen file reads.
what stays local, what leaves
Your machine
01
Your question
“who calls this?” 02
Local code understanding
40+ languages and formats · understood on your machine 03
The exact evidence
the declarations, callers, and lines, not whole files Provider
04
The model
your question and that evidence layer 01 of 4
don't pay twice
Don't pay for the same bytes twice
Most of a coding session repeats: the same instructions, the same files, the same command output. squeezy keeps that out of the bill.
Where the provider supports caching, squeezy keeps stable instructions and context cache-friendly, so repeated turns cost less.
When the same file or output would be sent twice, squeezy sends a short receipt that points back to the first copy, not the bytes again.
The model sees a compact tool index first and loads a full definition only when it's needed, which also keeps the cached prefix intact.
After an edit lands, squeezy trims the now-stale parts of earlier reads in place, so later turns don't re-buy lines the change already replaced.
layer 02 of 4
right-size turns
Right-size every turn
Not every turn deserves the biggest model or the longest history. squeezy matches the effort and the context to the task in front of it.
Simple, mechanical turns start on a small, fast model and step up to the main one only when the task turns out to be hard.
As a session grows, older turns fold into a short summary of goal, progress, and decisions, so turn 30 doesn't pay for turns 1 through 29.
Build, test, and search output is trimmed to the part the model can act on, with the full log one fetch away.
Short-lived subagents explore or review in their own context and hand back a summary, instead of bloating the main thread.
layer 03 of 4
stay in control
Control the bill, don't just watch it
Seeing where the tokens go only helps if you can act on it. squeezy turns the numbers into control: cap the spend, force a turn cheaper or stronger, and see exactly where it all went.
Set an optional session cost cap or per-step token ceiling and squeezy stops before it crosses the line, warning as you approach instead of after.
Send the next turn to the small model when you know it's easy, or to the main one when it isn't, without changing your defaults.
The cost view splits the session by model and by role, into input, output, reasoning, cache reads, and cache writes, in dollars where the provider publishes rates. The context view says how much of the window is in use right now.
what you type
/cost shows where the session's money went.
/cost budget 5 caps that session at five dollars.
/context shows how full the model's window is.
/router cheap and /router main send the
next message to the Cheap target -- your own model, where none is
configured -- or the active role's model.
layer 04 of 4
measured
and does that actually show up on the bill?
same model · same pricing · same grader