Squeezer – Use your idle Claude plan window to work through TODOs overnight

Let me search for the actual README content which has the key details about Squeezer: Good, I have solid details from the README. Let me write the article now:

A developer published Squeezer, an open-source Claude Code plugin and background daemon designed to work through a user's project TODOs during the idle hours of their Claude Pro subscription window. The tool, hosted at github.com/valk/squeezer under an MIT license, targets a specific inefficiency: paid Claude Code plan holders routinely leave large portions of their five-hour usage window untouched once they step away from the keyboard.

This piece covers how Squeezer orchestrates Claude Code sessions autonomously across multiple projects, how it communicates progress and decisions over Telegram, and what developers running on a Claude Pro plan should understand before setting it up. It is aimed at solo engineers and small teams who already use Claude Code for active development and want to reclaim idle compute time overnight or between working sessions.

Squeezer – Use your idle Claude plan window: what actually changed

Squeezer introduces a persistent background daemon that runs Claude Code headlessly using claude -p --resume <session-id> turns. Before Squeezer, the only way to run Claude Code continuously was to sit at the terminal yourself — the five-hour plan window reset would simply expire unused if you stepped away. Squeezer installs itself as a launchd service on macOS or a systemd --user service on Linux via the /squeezer:setup slash command, meaning the daemon survives reboots and crashes without additional configuration.

The daemon is structured around a per-project TODO backlog system. Each registered project gets its own todos/ directory under SQUEEZER_HOME (which defaults to ~/.config/squeezer). The orchestrator picks tasks from that backlog, executes them via headless Claude Code turns, and records its decisions in a durable worklog at SQUEEZER_HOME/state/worklog.md. When a five-hour usage window closes, Squeezer waits for the next window and resumes automatically — the same conversation thread is picked back up, preserving context across resets.

Squeezer – Use your idle Claude plan window: how it works

The setup flow is a three-step Claude Code slash command sequence. Running /squeezer:setup in Claude Code handles Telegram bot configuration, TODO directory initialization, and daemon installation. After setup, Squeezer reads three key configuration files from SQUEEZER_HOME: CLAUDE.md for agent context, ESCALATION_POLICY.md to define which decisions require human sign-off, and ROUTINE.md for task-selection logic. The templates/CLAUDE.md.template file is copied into place on first run as a starting point.

Communication flows through Telegram via an MCP tool called telegram_send. The model calls this tool proactively — either to summarize what it completed during a session or to escalate a decision it has flagged as genuinely in-doubt. Crucially, Squeezer is not designed to ask permission on every step; it only surfaces decisions that fall outside the bounds set by ESCALATION_POLICY.md. Rate-limit resets are handled transparently: the daemon long-polls Telegram while waiting and spawns the next headless turn as soon as the window reopens.

Squeezer – Use your idle Claude plan window: why it matters now

Claude Code's Pro plan enforces a rolling five-hour usage limit. For developers who use Claude Code in focused bursts — coding for two hours in the morning, then switching to meetings or sleep — the remaining usage capacity evaporates without producing any output. Squeezer reclaims that capacity by treating the Claude Code session as a background worker rather than an interactive terminal. The worklog at SQUEEZER_HOME/state/worklog.md provides an audit trail of every task the orchestrator picked and why, giving developers a readable record to review in the morning.

The multi-project design makes the economics more compelling for developers maintaining several repositories simultaneously. One daemon instance manages one TODO backlog per registered project, so overnight work is not pinned to a single codebase. The agent works through tasks in priority order, switches projects when one stalls, and reports back via Telegram rather than requiring the developer to check logs manually. For anyone already paying for a Claude Pro plan, the marginal cost of letting Squeezer run is zero.

Squeezer – Use your idle Claude plan window: who is affected

Squeezer is directly relevant to individual developers and small teams who hold a Claude Pro subscription and run Claude Code as their primary AI coding assistant. The dependency on claude -p --resume means it requires a Claude Code installation and a working Telegram bot setup — users without either cannot use Squeezer without first completing both prerequisites. The daemon targets macOS and Linux explicitly; the /squeezer:setup command installs to launchd or systemd respectively.

Developers who keep Claude Code open and supervised all day will see less benefit, since the tool is specifically optimized for the unattended case. Teams using Claude's API directly rather than the Claude Code CLI are similarly out of scope — Squeezer wraps the CLI's headless mode, not the raw API. The MIT license means teams can fork and adapt the backlog and escalation logic without restriction, which makes it tractable for organizations that need custom routing behavior beyond what ESCALATION_POLICY.md and ROUTINE.md provide out of the box.

Squeezer – Use your idle Claude plan window: what to watch

Builders evaluating Squeezer should verify a few things before running it against active codebases. The ESCALATION_POLICY.md file controls what decisions the daemon makes autonomously versus what it surfaces to the developer over Telegram — writing a thoughtful policy before the first overnight run is essential, not optional. A poorly scoped policy could result in the daemon making destructive or irreversible changes to a codebase without any human review. Similarly, the todos/ backlog should be seeded with clearly scoped, atomic tasks rather than open-ended goals, since the model must interpret each TODO without interactive clarification.

The project is early-stage, with no published version numbers or stability guarantees listed in the repository at time of writing. Potential users should confirm that headless claude -p --resume behavior in their Claude Code version is stable and that the session-id format the daemon relies on has not changed. Watching the worklog during initial runs is the safest onboarding path — reviewing SQUEEZER_HOME/state/worklog.md each morning until the escalation policy is well-calibrated will catch gaps before they compound across multiple autonomous sessions.