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 is not one bad answer. It is a loop that re-reads the same file five times, greps the same pattern across the whole tree, and rebuilds context it already had. Even a fast, cheap model turns slow and costly when the loop wastes its calls.

Squeezy puts a layer underneath the model. Your machine keeps its own understanding of your code and answers questions about it directly. Finding a definition, listing the callers of a function, outlining a module, reading the ten lines that matter: that work runs locally and comes back as a small, focused result instead of a wall of text.

The model then does the part only it can do: read that evidence and decide the next step. Repetitive lookup goes to your machine, where it is nearly free. Judgment, how to design the change, whether the diff is right, what a failing test means, goes to the model, where the tokens are worth spending.

• Lookup and navigation happen on your machine, not by pouring files into the prompt.
• Reasoning still runs on the model you chose, at full strength.
• You get fewer tokens on the wire and fewer wasted round trips, not a weaker model.

Local code understanding first, plain search as the fallback

When Squeezy needs to know something about your code, it asks its own index first. That index is a code knowledge database: every symbol in your project and how the symbols connect, who calls what, where each thing is defined, what refers to it. It is built from your files, on your machine, and updated as you edit. Questions like “where is this defined,” “what calls this,” and “what does this module look like” are answered from the index instead of by reading files into the prompt.

Each answer is a small piece of evidence: the file, the exact span, and a label for how it was resolved. A link the parser proved is marked differently from one best guess among several candidates, so you can tell a definition from a possibility. Squeezy does not dress a guess up as a fact.

Not everything fits the index. It covers 40+ languages and formats. Anything outside that set falls back to ordinary text search and file reading, and those tools describe themselves as the fallback rather than the confident answer. Every read and search is bounded: results are capped, and an oversized one is trimmed to a preview carrying a pointer to the rest, so a single search cannot dump hundreds of kilobytes into the conversation.

• Indexed navigation: find a definition, find callers and callees, outline a module, read only a symbol's signature, or only its body.
• Every answer carries a file, an exact span, and how confidently it resolved.
• Text search and file reads cover what the index does not, and are named as the fallback.
• A trimmed result is never bigger than the raw output it replaced, and the full original stays one call away.

Mode and Access: two settings you change on purpose

A session carries two settings, and you change both deliberately. Mode is the goal: Chat and Plan are read-only, while Build and Orchestrate may change files. Access is how much room the agent has inside what the mode permits. Ask prompts you before anything beyond safe in-workspace work; Auto lets a reviewer settle exact effects that grant it authority and sends the rest to you; Full settles ordinary consent without a reviewer and has to be enabled before you can select it. Shift+Tab cycles Mode, Ctrl+X, Tab cycles Access, and any modes you define yourself join the Mode ring after the built-ins.

Chat is conversation and exploration. Plan is design work that ends in a saved plan. Neither offers the model a tool that can edit a file, and an edit attempted anyway is refused, so you can weigh options with no risk that the agent quietly starts changing things. When you leave Plan for Build, the plan you wrote there comes with you.

Build is the normal implementation mode: edits, commands, and verification, each still checked against your permission settings. Orchestrate has the same capabilities but is delegation-first, steering broad work through subagents instead of editing from the main thread. Mode decides both what the model is offered and what is allowed to run, so the boundary holds on both sides.

Pick the mode at startup with --mode, or switch during a session with /chat, /plan, /build, and /orchestrate. /modes opens one page showing both axes together.

• Chat and Plan: read, search, navigate, design. No file-changing tool is offered or accepted.
• Build and Orchestrate: edits, commands, and verification, behind your permission settings.
• Orchestrate is delegation-first: broad work is steered through subagents.
• Access decides how often you are asked: Ask, Auto, or Full, and Full has to be enabled first.
• Shift+Tab cycles Mode and Ctrl+X, Tab cycles Access; /chat, /plan, /build, and /orchestrate jump straight to one.

Subagents: research that stays out of your conversation

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

So Squeezy hands the job to a subagent: a separate run with its own instructions, its own context, and a tool set scoped to the work. It does the legwork in its own space and returns a compact summary with the references behind it. The intermediate steps stay where they happened.

The explore, plan, and review roles cannot change files. The general-purpose worker can edit and run commands, under the same permission rules and approval prompts as your main turn, so nothing lands that you would not have approved inline. No subagent can start another, so fan-out stays flat and predictable. The read-only roles run side by side, and explore and review use a cheaper model from the same provider, because scanning and summarizing does not always need your headline one.

You can add subagents of your own as files in your project or your settings, each with its own instructions and model. One you wrote reads and searches only, unless you explicitly grant that one the right to write.

• For research and broad questions that would otherwise flood the main conversation.
• Isolated: own instructions, own context, no access to your transcript.
• Only a bounded summary and its supporting references come back.
• Flat by design: no subagent starts another, and the read-only roles run in parallel.
• Your own subagents load from files, read-only unless you grant one write access.

Turn routing: a cheaper model for the easy turns

Not every turn needs your most capable model. A lot of what you ask is mechanical: “run the tests,” “check out main,” “grep for TODOs under src.” Those are candidates for a smaller, faster model. Routing is on by default but does nothing until you point it at one: you name a cheap model, a more capable one, or both, and each runs on whichever provider you gave that model — usually the one you already configured, but another vendor if that is what you chose.

Left to itself, a turn starts on your main model; a turn you pinned with /router runs its very first step on the rung you named, provided that rung can carry it — a pinned cheap turn still has to fit the model's context window and to see any image the turn can reach, and steps up where it cannot. Some turns are held on your main model before the first request: a prompt carrying an image, unless you turn the image bypass off; non-image attachments totalling the size threshold you set or more, images being governed by the image bypass instead; a follow-up whose earlier context could not be summarized; and work that touches containers, package managers, or host sandboxing, unless you turn that bypass off too. If an unpinned turn that cleared those gates then calls tools, a short classification runs alongside those tool calls and can move the rest of the turn down to your cheap rung, or up to the more capable one where you named that instead; a pinned one is decided before the first request and never classified. A turn that answers in one step never pays for that classification.

If a turn on your cheap rung turns out harder than it looked, too many tool calls, repeated errors, a refusal, Squeezy steps it up to your main model mid-turn; an overflowing context or an error from the provider returns it there directly instead of stepping, provided the step has produced nothing yet and the failure is not your provider being overloaded. Where the recovery does run, the router will not drop below the rung it reached for the next few turns, so the following one does not flap straight back down. None of this watches a turn already on your main model or a more capable rung: that turn runs where it is.

Force a single turn with /router cheap, /router main, or /router expensive; bare /router opens the settings. Routing depends on what your provider offers and which Cheap model is configured, so it is not a promise that every simple-looking turn costs less. /cost reports how many turns were routed, how many escalated, what the classification cost, and the estimated net.

Verification: builds, tests, and linters as evidence

When a task needs proof that a change works, Squeezy runs your project's own commands, the build, the test suite, the formatter, the linter, and reads what comes back. “Did this edit break anything” is answered by running the tests, not by the model asserting it is probably fine.

Running your code is a separate act from reading about it. Asking the index a question never triggers a build or reaches the network. Executing something does, so any command that changes files or runs code is checked against your permission settings first. Shell commands also run inside an operating-system sandbox by default, using the strongest boundary the machine supports and warning you when it has to fall back. Set the sandbox to required and a command that cannot be confined is refused instead of run.

Command output is shaped before the model sees it. A noisy build log is reduced to the failures, the errors, and the counts, with a pointer to the full log if it is ever needed. The model gets clean evidence to act on, and you keep the complete record of what ran.

When the change is a web app, verification can reach the page itself. Squeezy launches a browser with its own isolated profile, walks the affected flow, and reads the console, the network log, and a screenshot as evidence, under the same permission gates as everything else. The browser and computer use page covers what that surface does and where it stops.

Working in the terminal

All of this runs in one terminal interface, built on the same idea as the rest of Squeezy: keep working while a turn runs, and make a long session navigable instead of a wall of scrollback. Two menus handle discovery. The command palette is one fuzzy-searchable list of everything you can run, key actions and slash commands together with your skills and saved prompt templates, each shown with its description and the key it is currently bound to. The action palette works on whatever entry is under focus and offers 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, fold or unfold it. Every chord is rebindable, from the Keybindings page of /config or from keyboard-shortcuts.toml beside your settings, and the palette shows the binding in effect rather than a default that may no longer be true.

You do not have to wait for a turn to finish. Press Enter while one is running and your next prompt is queued, then runs on its own as the turn ahead of it completes. A queue overlay lets you reorder, edit, or delete what is waiting, fold several prompts into a named group, pause a group so it is held back while the rest keep going, and promote one prompt to run next. A queued prompt can also carry a condition: run only if the previous turn succeeded, only if it failed, only if it edited files, or only when you start it by hand. A line above the composer shows how many prompts are waiting and which groups are paused.

Delegated work gets the same treatment. A subagent panel lists the session's subagents with role, status, elapsed time, tool count, and the cost each one reported; an unknown cost shows a dash rather than an invented number, and failures are flagged. You can filter the list by status, jump into a subagent's transcript and come back where you were, mark two finished subagents to compare their output side by side, and promote a useful result into a follow-up prompt, which fills the composer or joins the queue but is never submitted for you.

For reading back through a session, a transcript index buckets every entry by kind, user turns, assistant messages, reasoning, tool calls, errors, subagents, plans, and diffs, so jumping to the next tool call or counting the errors is a 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; a collapsed lane holding an error keeps its header visible, so a hidden failure never goes quiet. The status line is yours to build: choose from a fixed catalog which facts appear and in what order, provider and model, session cost against your cap, context left, cache activity, tool counts, the active mode and sandbox, connected servers, then save that layout to your settings or to the project's so a team shares one bar.

• Command palette: one fuzzy list of every key action, slash command, skill, and prompt template, each with its current binding.
• Prompt queue: Enter queues a follow-up mid-turn; reorder, edit, group, pause, condition, or promote what is waiting.
• Subagent panel: role, status, elapsed, tool count, and reported cost per row; jump in and back, compare two results, promote one into a follow-up.
• Transcript index and foldable lanes: jump by entry kind and collapse the noise, with errored lanes keeping a visible header.
• Status-line builder: choose the facts your bar shows, and save the layout to your settings or the project's.

Three walkthroughs

A plan turn. You are in Plan mode and ask, “how does request retry work, and where would I add a backoff cap?” Squeezy answers from the index first: it locates the retry logic, pulls the signatures and the callers that depend on them, and reads only the slices that matter. No full-file dumps, no editing tools in play. The model proposes an approach: where the cap would live, what it would touch, the trade-offs. Nothing changed on disk, and the plan follows you into Build.

A build turn. In Build mode you say, “add the backoff cap we discussed.” Before editing, the agent asks the index for the neighborhood around the change, the declarations, callers, references, tests, and config the edit touches, and the edit is bound to that neighborhood. It applies under your permission settings, then runs the tests and reports what passed and what failed. A failure comes back trimmed to the relevant lines and becomes the next piece of evidence.

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

Related

• Cost-saving strategies
• Languages
• Browser & computer use
• Sessions