Install squeezy and start it in your repo.

Install

Nothing to install yet. squeezy has no published release, and its source repository is not public, so none of the four commands below can fetch anything today. They are not placeholders: the installer address, the Homebrew tap, and the Windows package id are the ones squeezy's own release packaging is built on.

On macOS and Linux the one-line installer is the shortest path. It works out which operating system and processor you are on, checks the download against its published SHA-256, runs the new program once before it replaces anything, and installs into ~/.local/bin unless you set SQUEEZY_INSTALL_DIR. If that directory is not on your PATH, it prints the line to add. Homebrew covers macOS on Apple Silicon plus x86_64 Linux, from one tap. Windows uses winget. With a Rust toolchain you can build from source instead, which needs Rust 1.96.0 or newer.

curl -fsSL https://raw.githubusercontent.com/panicless/squeezy/main/install.sh | sh

brew install panicless/tap/squeezy

cargo install --git https://github.com/panicless/squeezy squeezy squeezy-browser-bridge --locked --profile release-install

winget install panicless.Squeezy

The release builds cover macOS on Apple Silicon, Linux x86_64 and aarch64 as static binaries that run on any distribution without matching its system libraries, and Windows x86_64 and aarch64.

One caveat on the from-source path: on Windows it builds the squeezy and browser host, without the two helper programs the Windows shell sandbox needs, squeezy-sandbox-setup.exe and squeezy-sandbox-spawner.exe. Without them shell commands run with no sandbox at all. squeezy still cleans up the whole process tree when a command ends, but nothing isolates the filesystem or the network, and squeezy doctor reports that in its sandbox row. The winget package and the Windows release archive both carry all four programs.

First start

Run squeezy in the repository you want it to work on. The first interactive start asks four questions: your theme and background, which provider to use, which of that provider's models, and how much reasoning effort to spend. A fifth step appears only when the provider you picked still needs credentials, and it either takes an API key or starts a sign-in for a subscription you already pay for. A model running on your own machine needs neither, so that step does not appear.

The provider list says what each row would take before you commit to it: ready when squeezy already found a working credential, naming what made it work, and needs a key, needs sign-in, or needs setup when it did not. Its first row, Configure later, ends setup there and opens squeezy with no provider written down, so the next launch asks again rather than recording an answer you never gave.

Your answers go to your user settings file, $SQUEEZY_HOME/config/user-settings.toml, so setup runs once. /config changes any of it later.

Setting SQUEEZY_BUILD_PROVIDER_PROFILE or SQUEEZY_BUILD_BASE_MODEL, or passing --provider or --model, skips setup and uses what you named. Anything left unnamed falls back to the built-in default, the openai provider, so a key exported for some other service does not select that service on its own.

squeezy doctor
squeezy doctor --probe

squeezy doctor prints one row per check: which settings files were merged, which environment variables overrode a setting, the credential for your provider, where sessions, state, and caches are stored, and whether the shell sandbox can run on this machine. It exits 1 when a check fails and 0 otherwise, so it works as a gate in a script. --probe adds live checks. For most providers that is one small request confirming the key and the address it is calling; a few are verified against the stored credential instead, with no request. If you have MCP servers enabled it also reaches each one, which starts every enabled stdio server as a child process. Help & troubleshooting covers it in full.

Upgrade

squeezy checks for a newer release on its own, at most once a day, and offers the upgrade rather than taking it. The prompt takes four answers: update now, leave it, leave it and drop the reminder for this launch, or decline this version for good.

You can drive the same machinery yourself. squeezy update check forces a live check past that daily cache. squeezy update install applies the newer release, or runs your package manager's own upgrade when squeezy can see it was installed by one. squeezy update status prints the running version, the newest one it has seen, how this copy was installed, and anything you have skipped or snoozed.

squeezy update status
squeezy update install

To stop being asked, squeezy update skip <version> declines one version for good and squeezy update snooze 7d quiets the prompt for a set time. SQUEEZY_DISABLE_UPDATE_CHECK=1 turns the check off for one run, and check_enabled = false under [update] in your settings turns it off for good.

Ask squeezy about itself

You do not need to leave the session to learn the product. /help lists every topic, /help <topic> opens one, and /help /<command> explains one of the commands you type with a slash. Each of those is answered from documentation compiled into the program, so nothing is fetched and no model is called. A question in your own words is the one case that costs a turn: a helper searches that same bundled material and answers from it. Every answer ends with a line naming where it came from. Help & troubleshooting has the detail.