Control the bill
A coding agent should not be able to surprise you with a bill. Squeezy keeps the running spend and how full the conversation is in front of you the whole time, breaks either one down on request with /cost and /context, and stops a turn before it crosses a limit you set.
contents
contents
The number is already on screen
You do not have to run anything to see what a session is costing. Squeezy's status line carries the estimated spend and a small gauge for how much of the context window is in use. The gauge stays quiet while there is room, warms once three quarters of the window is gone, and turns red past nine tenths, so the one budget a session can exhaust without warning is the one you cannot miss.
Set a spending limit and the spend figure gains a second half: what you have spent, the cap, and how far through it you are. If the model you are on has no published prices, the line says the limit is inert rather than letting you believe a guardrail is on when it cannot be.
What gets counted
Squeezy keeps two accounts of every turn and shows you both. One is what the provider reported billing. The other is Squeezy's own measurement of the request it assembled, split by which part of the conversation contributed what. The provider account tells you the bill was high; the local one tells you what to cut.
- Input: the prompt the model saw.
- Output: everything the model generated, billed at the output rate.
- Reasoning: the share of that output that was the model thinking rather than text you can read. You pay for it either way, so it gets a column of its own.
- Cached input: prompt the provider served from its cache at a discount. A healthy number here is proof that caching is working.
- Cache write: the pass that seeds the cache. Not every provider reports it separately, so on some it reads as zero.
- Dollars: an estimate from those counts and local prices, shown for the models Squeezy has prices for.
/cost, where the money went
Run /cost for the whole session on one screen. It opens with what you have spent and what Squeezy kept off the bill, then breaks the spend down by model and by role: the main conversation, subagents, and the side calls Squeezy makes on your behalf, such as judging whether a turn can run on a cheaper model, auto-reviewing a permission request, summarizing an overlong transcript, or filing a durable note after a turn. Work that never produced an answer for you is priced in rows of its own instead of hiding inside one total.
Below that: how much of your input the provider served from cache, what the tools and subagents did, how many calls were made and returned and how many errored or were denied, where the time went, and which limits are in force. The report ends on the caveat it should: the dollar figure is a local estimate against published rates, not a billing authority.
When there is a saving to show, /cost also states the baseline it is measured against: the bill plus everything avoided, which is what the same session would have cost with none of Squeezy's savings work. That baseline is a modeled comparison, not a charge, and the report says so.
/cost
/cost saving # the savings alone, short enough for a small terminal
/cost history # the retained 90-day rollup across past sessions
/cost why # how a savings figure is built, and what it does not claim/context, what is filling the window
Run /context to see the current conversation laid out by where its space is going. The first line is how much of the window is in use, as a count and a share, and the exact figure at which Squeezy will start folding older turns into a summary on its own.
Then each source that is actually taking space gets a row, largest first: message text and tool arguments, tool output, loaded skills, the tool descriptions from connected servers, memory, reasoning, images, attached files, and Squeezy's own fixed overhead. The rows add up to the total, so nothing hides in a remainder. The closing line names the biggest thing you can cut and what to do about it: narrow the reads, run /compact, drop a stale attachment, lower reasoning effort for routine turns.
That is what turns a vague sense that context is filling up into one decision you can make.
/context
/context skillsA panel while you work, reports when you are not
/cost is a snapshot. For a readout that stays up, open the live cost panel with Ctrl+X B. It shows what this session has spent, what it has saved and against which baseline, the mechanisms that moved the most, and a rollup of earlier sessions by provider and model.
squeezy savings answers the same question from a plain shell with nothing running: a breakdown by mechanism, by provider and model, or by hour, day or week, printed as text, JSON, or CSV. squeezy perf is its opposite number and reports the work that was repeated for nothing across past sessions. Both read the stored record directly, so neither needs a live session.
squeezy savings --export-html writes one self-contained HTML file, with no JavaScript and nothing fetched from the network, for sending on or keeping.
squeezy savings --by time --time-bucket daily
squeezy savings --by mechanism --format csv
squeezy savings --export-html cost-report.html
squeezy perf --jsonSetting a limit
Watching is always on; stopping is something you switch on. Give a session a dollar cap, a ceiling on the input tokens any one step may send, or both. Before each step Squeezy checks the running total against your number, and if that step could cross it the turn stops with a reason instead of spending past it. The check is deliberately pessimistic: it assumes the model will use its full output allowance. You get one heads-up on the way, at 85% of the cap by default.
Both limits are off unless you set them, so out of the box Squeezy reports on spend rather than refusing it. /cost budget 5 caps the session you are in at five dollars without touching a file, and /cost budget off lifts it again. The same keys live in the project file a repo can commit, where they may tighten what your own settings allow but never loosen it, so a team can hand every checkout the same ceiling.
One more control covers the case where nothing is over budget but nothing is happening either: a failing-test count that has stopped dropping, search after search that narrows nothing. Squeezy reminds the model what the session has cost, compacts a little earlier, and once the stall is severe pauses the turn with a summary and asks whether to continue, change course, or stop. This one is on by default and needs no cost limit configured: the evidence it asks for is deliberately hard to reach, and a turn still making progress is never touched. Nothing is lost and the session carries on normally. Set it to eager to be interrupted sooner, or off never to be interrupted.
[budgets]
max_session_cost_usd_micros = 5000000 # stop the session at ~$5.00 of estimated spend
cost_warn_percent = 85 # warn once at 85% of the cap
max_step_input_tokens = 200000 # refuse a step whose input would exceed this
futility_governor = "conservative" # off | conservative | eager: check in on a stalled, still-spending turnBudgeted autonomy: give a long-running goal a spending limit
A goal is a persistent objective the agent keeps pursuing across turns: set one with /goal, and when a turn ends with the goal still open and real progress made, Squeezy re-prompts itself instead of waiting for your next message. That autonomy is bounded on every side. Continuing requires at least one substantive tool call completed since the last continuation, so a step of errors or denials never reads as progress; it stops after eight self-continuations; a terminal error marks the goal blocked rather than re-arming it; and it runs only in Build mode, so the read-only modes never drive extra turns.
The budget is what makes it a spend instrument. /goal <objective> --budget 200k caps the goal in cost-weighted tokens: ordinary input and output count at face value, cache reads at about a tenth of that, cache writes at rather more, so the counter tracks what you are spending rather than raw volume. When usage reaches the cap the goal is marked limited and the model is told, once, to wrap up, summarize progress, and leave a clear next step instead of starting new work. Raising the budget or removing it releases the goal; nothing un-caps itself.
While a goal exists, a chip above the input line names its state and its usage against the budget. The goal survives /resume with its accounting intact, and /goal pause, resume, complete, and clear stay yours at any time.
/goal migrate the test suite off the legacy runner --budget 200k
/goal show # objective, status, time and tokens spent
/goal pause # stop self-continuation without losing the goal
/goal budget off # remove the capWhat depends on the provider
Some figures are only as complete as what the provider reports. Counters fill in as usage arrives from the API. Cache-write input does not exist everywhere, so it can read as zero where a provider does not separate a first cache write from an ordinary miss, and Squeezy will not invent a line it cannot substantiate. A dollar cap needs published prices for the model you are on; without them Squeezy tells you the cap cannot be enforced rather than leaving you to assume it is.
The per-source breakdown in /context is Squeezy's own measurement of the request, not a re-run of the provider's tokenizer. It is accurate enough to steer by, and it corrects itself: every turn compares the estimate against the count the provider reports back, and the correction carries into later sessions.
Why this comes first
Every other saving on this site is a decision you would otherwise be making blind. The cached-input figure is how you confirm caching is paying off. The per-source breakdown is what makes the limits on tool output worth touching. The share of the window in use is what compaction reads to decide when to fire. Measure, change one thing, look again: read /context, see that tool output is your largest source, narrow the reads, and watch the next /context come down.