Sleepless Agent: a Claude Code daemon driven from Slack
🤖 24/7 AI agent that maximizes Claude Code Pro usage via Slack. Auto-processes tasks, manages isolated workspaces, creates Git commits/PRs, and optimizes day/night usage thresholds.
At a glance
- What is it?
- Sleepless Agent wraps the Claude Code CLI in a 24/7 Python daemon that takes tasks from Slack or the sle CLI, runs each one in an isolated workspace, and can commit the result. It is a personal throughput tool for one Claude Code Pro seat, not a multi-tenant job runner.
- Who is it for?
- Adopt Sleepless Agent if you already pay for Claude Code Pro, keep your work in git repositories, and want a Slack command to hand off tasks that run unattended. Do not adopt it if you need per-task cost attribution, an audit trail for regulated work, or a scheduler that can run without a logged-in Claude Code CLI on the same machine.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 171 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is an idle subscription, not a missing agent framework
Claude Code Pro is a flat monthly seat with usage limits, and the README opens with the observation that many subscribers do not use it overnight. Sleepless Agent exists to consume that idle capacity: it runs as a daemon, accepts tasks, and executes them through the Claude Code CLI while you are asleep. The intended user is an individual developer or a small team with one or a few seats, working in git repositories, who already thinks in terms of Slack messages and pull requests.
The scope is narrower than the phrase "AgentOS" suggests. There is no hosted control plane, no multi-tenant isolation story, and no billing model. The daemon runs on a machine you own, with your Claude Code login, against your repositories. Treat it as a personal background worker with a chat interface, not as infrastructure you would expose to an organisation.
Slack in, SQLite queue, isolated workspace, git branch out
The data flow described in the README is linear. A task enters through a Slack slash command such as /think, or through the sle think CLI when Slack is not configured. It lands in a SQLite-backed task queue that persists across daemon restarts. A scheduler picks work according to priority, and each task is executed in its own isolated workspace, which is what allows parallel execution rather than serialised runs.
Execution is delegated to Claude Code through the Claude Code Python Agent SDK, so the daemon is a supervisor rather than a model client: the README states that a Claude API key is no longer needed because the CLI handles authentication. When a task finishes, the result and its metadata are stored, and git management can produce a commit on a branch. The example output shows a branch named feature/backend-42 and a pull request link, which implies gh CLI involvement for the PR step.
There is a deliberate split in how results are handled. The README describes "Hybrid Autonomy": random thoughts are applied automatically, while serious tasks, marked with -p project-name, require review. That distinction is the most interesting design decision in the project, because it is the only thing standing between a stray Slack message and an unreviewed commit in your repository.
Getting it running: pip, claude login, sle daemon
Installation is a single pip command, pip install sleepless-agent, or an editable install from a clone with python -m venv venv followed by pip install -e . Python 3.11 or newer is required. The Claude Code CLI is a hard prerequisite and is installed separately with npm install -g @anthropic-ai/claude-code, then authenticated once with claude login, which the README says opens a browser. Verifying with claude --version is the documented check.
Slack is explicitly optional. Without it, sle daemon starts the worker, sle think "Research async Python patterns" queues a task, and sle check prints queue state. The status output shown in the README includes a daemon indicator, pending and in-progress counts, a usage percentage with a day threshold, and the current task. Results are retrieved with sle report followed by a task number.
If you do want Slack, the setup is the standard Socket Mode path: create an app, enable Socket Mode, generate an app token beginning with xapp-, register the slash commands (/think, /chat, /check, /usage, /cancel, /report, /trash), add bot scopes including chat:write, commands and reactions:write, subscribe to message.channels and message.groups for chat mode, then install and copy the xoxb- token. Both tokens go into a .env file created from .env.example. Log verbosity is controlled with SLEEPLESS_LOG_LEVEL=DEBUG.
The Slack dependency is smaller than the page layout implies
The README devotes a long section to Slack app configuration, which makes the project look Slack-first. It is not. A callout states that every feature is available through the CLI, and the optional setup path is presented before the Slack instructions. That ordering is a fair signal: the daemon, the queue, the workspaces and the git automation are the product, and Slack is an intake channel with a chat mode bolted on.
The practical consequence is that you can evaluate Sleepless Agent without creating a Slack app, without workspace admin rights, and without the token handling that comes with a bot in a shared channel. For anyone who is uneasy about putting an autonomous commit-producing agent behind a chat command, the CLI path is the lower-risk starting point. The README's own prerequisites list marks Slack workspace admin access as optional for exactly this reason.
What the documentation does not settle
The usage optimisation is the least specified part of the project. The description mentions optimising day and night usage thresholds, and the status output shows a usage percentage against a day threshold of 95 percent, but the README does not give the default values, the config keys that set them, or what happens to a queued task when the threshold is crossed. Whether work pauses, defers to a night window, or simply warns is not stated in the material available. Anyone relying on this to stay inside plan limits should read the source before trusting it.
Isolated workspaces are described but not defined. The README does not say whether isolation means a git worktree, a clone, a container, or a directory. That matters for disk usage and for how much state leaks between tasks, and it is the kind of detail that should be verified by inspecting the repository rather than assumed.
There is also the authentication model. Because the daemon drives a CLI that was authenticated interactively with claude login, the whole system depends on a logged-in session on that machine. Token expiry, a headless server without a browser, or a second user on the same host are all unaddressed in the README. This is a real constraint, not a footnote: a 24/7 daemon whose credential can expire silently is a daemon that stops producing work at some unpredictable hour.
Compared with a plain cron job and the claude CLI
The honest alternative is a cron entry that pipes a prompt into the Claude Code CLI and commits the result. That approach has no queue, no persistence, no workspace isolation, and no status view, but it also has no daemon to keep alive and no Slack tokens to rotate. Sleepless Agent adds the queue, the per-task workspace, the priority scheduler, the result store and the review-versus-auto-apply split. If your actual need is one nightly script, the cron job is the smaller commitment.
A second comparison point is a general workflow orchestrator with an LLM step, such as running Claude Code inside an existing CI job runner. That route gives you scheduling, secrets management and logs you already operate, at the cost of the conversational Slack intake and the interactive chat threads. Sleepless Agent's differentiator is not the execution engine, which is the Claude Code CLI either way, but the intake and feedback loop: you type a thought into Slack and read a report back.
Maintenance surface, releases and the MIT licence
The project is small and young. Three releases are listed: v0.1.0 in October 2025, v0.1.1 described as an architecture overhaul and documentation update one day later, and v0.1.2 a dependency update the following day. The last push to the default branch is dated 2026-03-29. An architecture overhaul one day after the initial release is a signal that the internal design was still moving in the first week, so pinning a version and reading the diff between releases is reasonable practice here.
The maintenance cost sits mostly outside the package. You are responsible for a Python 3.11+ environment, a globally installed Node package for the Claude Code CLI, an authenticated Claude session, git, and optionally gh. Each of those can break the daemon independently, and the README's own troubleshooting section for the sle command not being found on Windows or WSL, resolved by locating the user scripts directory with python -m site --user-scripts and adding it to PATH, is an early example of environment friction.
The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement with no copyleft obligation. It says nothing about the terms of the Claude Code CLI or the Claude Code Pro plan, which are separate agreements you accept by installing and logging in, and nothing here should be read as legal advice.
Editorial conclusion
Adopt Sleepless Agent if you already pay for Claude Code Pro, keep your work in git repositories, and want a Slack command to hand off tasks that run unattended. Do not adopt it if you need per-task cost attribution, an audit trail for regulated work, or a scheduler that can run without a logged-in Claude Code CLI on the same machine. Before committing, verify three things: that claude login succeeds non-interactively in the environment where sle daemon will run, that gh is authenticated if you want the automatic PR creation the README advertises, and that the day and night usage thresholds behave the way you expect against your own plan limits, since the README does not document their default values.
Community notes