How it works

The core idea: cheap work local, hard work on the model

A coding agent pays for every token it sends and receives. The expensive failure mode isn't a single bad answer, it's an agent that re-reads the same file five times, greps the same pattern across the whole tree, fans out into dead-end edits, and re-derives context it already had after every time the conversation gets trimmed. Even a fast, cheap model becomes slow and costly when the loop wastes its calls.

Squeezy's bet is that the right place to fix this is the ground the agent stands on, not the model. Your machine maintains a local understanding of your code and answers structured questions about it directly. Searching, listing, mapping the shape of a module, finding callers, reading just the part of a file that matters, that work runs locally and returns a small, focused result instead of a wall of raw text.

The model then spends its tokens on the part it's good at: reading that focused evidence and deciding the next step. Deterministic, repetitive work goes to the CPU, where it's nearly free. Non-repetitive judgment, how to design the change, whether the diff is right, what the failing test means, goes to the model, where the tokens are worth spending.

• Repetitive/deterministic work (search, navigation, reading slices): done locally, billed at almost nothing.
• Hard reasoning (design, judgment, interpreting results): done by the model, where tokens earn their cost.
• The result is fewer tokens on the wire and fewer wasted round-trips, not a different or weaker model.

Local code understanding first, search as a labeled fallback

When Squeezy needs to know something about your code, it asks its local understanding of the project first. It keeps a code knowledge database, a map of the symbols in your project and how they relate, who calls whom, where things are defined, what references what, built from your code on your machine and updated as files change. Questions like “where is this defined,” “what calls this,” and “what does this module look like” are answered from a local index rather than by reading files into the model.

Each answer comes back as a compact piece of evidence: the path, the exact span, and a confidence label that says how sure the answer is. A direct match is marked differently from a best-guess candidate, so the agent (and you) can tell “this is definitely the definition” from “this is one of several possibilities.” Squeezy doesn't dress up a guess as a fact.

Not everything fits the knowledge database. Squeezy covers 22 languages for local code understanding; files in other languages, plain text, and config are handled by ordinary search and reading. Those fallbacks are always available and are clearly labeled as fallbacks rather than presented as confident answers. All of these reads and searches are bounded, results are capped and trimmed so a search across a huge repository can't dump hundreds of kilobytes into the conversation, with a pointer to retrieve the full content on demand.

• Indexed navigation: find a definition, find callers/callees, map a module, read just the signature or just the body of a symbol.
• Every answer carries a path, an exact span, and a confidence label so guesses aren't mistaken for facts.
• Bounded search and reads cover the gaps, clearly marked as fallback.
• Large results are trimmed with a recovery pointer, never silently dropped.
• A trimmed result is never larger than the raw output it replaces, and the full original stays recoverable on demand.

Plan mode and build mode: an explicit switch

A Squeezy session is always in one of two modes, and the switch between them is something you do on purpose. Plan mode is for understanding and design: the agent can read, search, and navigate your code, but the tools that change files aren't on the table, they aren't offered to the model, and an attempt to use one is refused. You can explore a question and weigh options without any risk that the agent quietly starts editing.

Build mode is for implementation. Here the file-changing tools become available, gated by your permission settings, so the agent can propose and apply edits, run commands, and verify its work. The mode is part of how tools are presented and how permissions are checked, so the boundary holds on both sides.

Making the switch explicit keeps the two intents from blurring. You decide when exploration ends and implementation begins, rather than discovering after the fact that an exploratory question turned into a pile of edits. You move between them with a mode setting at startup or a slash command during the session.

• Plan mode: read, search, navigate, design, no file mutations offered or accepted.
• Build mode: edits, shell, and verification available behind your permission policy.
• The mode gates both what's advertised to the model and what's allowed to run.
• You control the transition with /plan and /build.

Subagents: delegating research to an isolated context

Some questions touch a dozen files and take many steps, “how does authentication flow through this codebase,” “which subsystems would a change to this type affect.” Done inline, all the intermediate searching and reading piles up in the main conversation, and you re-send that pile on every later turn even though you only needed the conclusion.

Squeezy handles this by delegating to a subagent: a separate, isolated run with its own short instructions, its own scratch context, and a tool set scoped to the job. The general-purpose worker can edit and run, while the typed explore, plan, and review roles are restricted to reading and searching. The subagent does the legwork entirely in its own space, and what comes back is just a compact summary and a short trail of supporting references. The dozen tool calls and intermediate reasoning stay behind; only the answer crosses back.

Subagents are kept flat: none can spawn another, so fan-out stays predictable. The general worker's edits and commands go through the same permission policy and approval prompts as your main turn, so nothing changes that you wouldn't have approved inline; the read-only roles stay read-only. Several can run at once, so a multi-part investigation finishes in roughly the time of its slowest branch, and the read-only roles run on a cheaper tier since browsing and summarizing doesn't always need the headline model.

• Used for research and broad questions that would otherwise flood the main context.
• Each subagent is isolated: own instructions, own scratch space, no access to the main transcript.
• Only a bounded summary plus supporting references returns to the main conversation.
• Flat by design: the general worker can edit and run under your permission policy, typed roles stay read-only, no subagent spawns another, and multiple can run in parallel.

Turn routing: a cheaper model for the easy turns

Not every turn needs the most capable model. A lot of what you ask is mechanical and well-specified: “run the tests,” “check out main,” “grep for TODOs under src.” These are candidates for the same provider's smaller, faster tier. When pricing and model configuration make a cheaper rung available, routing can reduce spend; if the turn stops looking simple, Squeezy escalates back toward the parent model.

Squeezy classifies each turn before it starts. Structural gates keep risky or context-dependent turns on the parent model, then eligible turns use a JSON-constrained provider-local judge to choose a cheap, medium, or strong rung. If a turn turns out harder than it looked, through too many tool calls, repeated errors, or uncertainty signals, Squeezy steps it up a rung mid-turn and stays on the stronger model briefly so a follow-up does not flap back down.

Routing is on by default and never crosses providers. It depends on provider metadata and configured cheap models, so it is not a guarantee that every simple-looking turn is cheaper. You can toggle it for the session or force a single turn with /cheap, /parent, and /router, and the accounting panel shows when routing fired and what it saved.

Verification: builds, tests, and linters as evidence

When a task needs proof that a change works, Squeezy runs your project's own build, test, formatter, linter, or benchmark commands and treats the result as evidence to reason about. “Did this edit break anything” is answered by running the tests and reading the output, not by the model asserting it's probably fine.

Verification is explicit and separate from navigation. Looking something up in the code knowledge database never quietly triggers a compiler or reaches an external service, reading about your code and acting on your code are different operations. Commands that change things or run code go through your permission policy, and shell commands run behind an additional sandbox layer when you enable it.

Command output is shaped before it reaches the model. A noisy build log is distilled into the parts that matter, the errors, the failures, the diff, with a pointer to the full output if it's needed. So verification gives the model clean evidence to act on, while you keep an auditable picture of exactly what was run.

Working in the terminal

All of this runs inside one terminal interface, and the interface is built around the same idea as the rest of Squeezy: keep the work flowing while a turn runs, and make a long session easy to navigate instead of a wall of scrollback. Two surfaces handle discovery. A universal command palette is one fuzzy-searchable list of every command, the rebindable key actions and the slash commands together, each shown with its description and current binding; you type a few letters, press Enter, and a command that takes an argument is handed back to the composer to finish. A contextual action palette acts on whatever entry is under focus, offering only the verbs that apply to it, copy the entry, copy its code, copy a tool's output, quote it into the composer, jump to it, expand or collapse it, so the menu is short and never lists something that can't run.

You don't have to wait for a turn to finish to keep going. Pressing Enter while a turn is running queues your follow-up instead of rejecting it, and each queued prompt drains and runs automatically as the turn ahead of it completes. A reorder overlay lets you move prompts up and down, edit or delete a queued one, multi-select several and fold them into a named group, pause a group so its prompts are held back from the drain while the rest keep running, and run a selected prompt next by promoting it to the front. The queue is its own line above the composer showing how many prompts are waiting and which groups are paused, so a held-back batch is visible without opening anything.

Delegated work gets the same treatment. A subagent timeline lists the session's subagents on a navigable panel, each row carrying the role, status, elapsed time, tool count, and reported cost where the child sent one, with failures and cap-rejections flagged for attention; an unknown cost reads as a dash rather than an invented number. Hovering a row previews its latest activity without resizing the panel, and a jump opens that subagent's transcript while remembering where you were so you can return. You can mark two finished subagents and compare their outputs side by side, and promote a useful result into reviewed follow-up work, distilled to clean text and dropped into the composer when you're idle or queued behind the running turn, never auto-submitted.

For reading back through a session, a transcript index buckets every entry by kind, user turns, tool calls, errors, reasoning, subagents, plans, and diffs, so jumping to the next tool call or counting the errors is a direct lookup rather than a scroll. Dense entries split into foldable lanes, assistant text, reasoning, tool input, tool output, diffs, so you can collapse the noise and keep the signal; a collapsed lane that holds an error still shows its header, so a hidden failure never goes quiet. A full-transcript overlay opens the whole conversation in its raw, expanded form for close reading and copy, separate from the running main view.

The status line is yours to build. A picker lets you choose, from a fixed catalog, exactly which facts show in the bar and in what order: provider and model, session cost against your cap, context window remaining or used, cache-hit activity, tool counts, the active permission and sandbox mode, connected MCP servers, and more. You can save the layout to your own settings or to the project's, so a team can share one standard bar, and the live preview uses the same renderer as the status line itself. Each surface costs nothing until you open it, and every mouse affordance has a keyboard twin routed through the same handler, so the two paths can't drift.

• Command palette: one fuzzy list of every key action and slash command, with bindings; argument commands hand back to the composer.
• Prompt queue: Enter queues a follow-up mid-turn; reorder, edit, delete, group, pause a group, and run-selected-next, with the count and paused groups shown above the composer.
• Subagent timeline: status, elapsed, tool count, and reported cost per row, failures flagged; preview, jump-and-return, compare two outputs, and promote a result into reviewed follow-up.
• Transcript index and foldable lanes: jump by entry kind, collapse the noise, with errored lanes keeping a visible header; a full-transcript overlay for close reading.
• Status-line builder: pick the surfaces you want, cost, context, permission and sandbox mode, MCP, cache activity, and save the layout to user or project settings.

Three walkthroughs

A plan turn. You're in plan mode and ask, “how does request retry work, and where would I add a backoff cap?” Squeezy answers from local code understanding first: it locates the retry logic in the knowledge database, pulls the relevant signatures and the callers that depend on them, and reads just the slices that matter, no full-file dumps, no editing tools in play. With that focused evidence, the model proposes an approach: where the cap would live, what it would touch, and the trade-offs. Nothing changed on disk; you got understanding and a plan.

A build turn. You switch to build mode and say, “add the backoff cap we discussed.” The agent proposes the edit using the impact context from the knowledge database (it already knows what this code touches), applies it under your permission policy, then verifies: it runs the test suite, reads the shaped result, and reports what passed and what failed. If a test fails, the failure output, trimmed to the relevant lines, becomes the next piece of evidence, and the agent iterates.

An exploration. You ask a broad question: “what would break if we changed the session token format?” This is wide and multi-step, so Squeezy delegates it to a read-only explore subagent. In its own context the subagent maps the call sites, follows the references across modules, and reads the relevant slices, dozens of steps that never touch your main conversation. It returns a compact summary: the affected areas, the risky spots, and a short trail of references. Your main thread gains the conclusion and stays light.

Related

• Cost-saving strategies
• Languages
• Sessions