Nightshift spends your leftover model budget on pull requests nobody asked for

An overnight agent that only ever opens pull requests

Nightshift is described as using your leftover Claude or Codex budget to surprise you with useful pull requests, with the instruction to love them or leave them.

The premise is that your token allowance resets every week, so you might as well use it. The tool runs overnight, finds things that are silently accumulating while you ship features, and turns each one into a pull request. The categories it names are dead code, documentation drift, test gaps and security issues, plus more than twenty other kinds of finding. The comparison in the description is a Roomba for your codebase: it runs overnight, and the worst case is that you close the pull request.

The safety model is the whole point and it is stated without hedging. Everything lands as a branch or a pull request, it never writes directly to your primary branch, and the entire rollback plan is that you close the thing you do not want. The feature list calls this zero risk, and in the narrow sense of the primary branch it is accurate.

The four headline features are a budget aware mode that uses the remaining daily allotment and never exceeds a configurable maximum, defaulting to 75 percent, a multi-project mode where you point it at your repositories and it already knows what to look for, the pull request model, and a developer experience argument built around CLI defaults, clear output and reports.

There is also a line at the very top of the readme that tells you to check whether you are running in Sidecar, with a command to run for capabilities, which suggests the tool behaves differently depending on the environment it is launched from, and that the environment it is running in is worth knowing about before you trust it.

The audience is a developer with a subscription allowance they are not using and a repository that has accumulated the kind of neglect that a machine is good at fixing. It is not a team tool in its current form.

The permission settings are where the real risk sits

The minimal configuration example in the readme is worth reading closely, because two of its lines describe a much bigger decision than the budget numbers do.

The provider block sets a data path and a permission flag for each provider. For Claude it enables the provider, points at the data directory with a path like ~/.claude, and sets dangerously_skip_permissions to true. The Codex block does the same with its own data path.

That flag is the name of the risk. The agent runs with permission checks skipped, which in a tool that executes a coding agent against your repository means it is not asking before it reads, writes, runs commands, and pushes a branch. The default in the shipped minimal example is to skip those checks, which is a choice made for the unattended overnight case, since an interactive prompt at 2am is not an option.

The pull request model limits the damage to your default branch, and it is a real limit. It does not limit the damage to your machine, to your credentials, to your token spending, or to the branches it creates, which is why a repository that receives surprise branches is not a good place for an agent running with permissions skipped.

So the sensible reading is that the zero risk claim applies to the merge decision, not to the execution. The configuration is where you decide how much execution risk you are willing to take, and the default example is the aggressive end of that spectrum.

The other thing in the configuration that deserves attention is the schedule. The minimal example runs a cron expression at 2am every day, which is the nightly model the tool is designed around, and the scheduling documentation is linked separately from the configuration guide for people who want a different cadence.

Budget awareness is the mechanism, not a feature

The budget system is the part of Nightshift that is genuinely different from a scheduled coding agent, because it is built around the fact that the subscription allowance resets rather than being consumed linearly.

The configuration carries a budget block with a mode set to daily, a maximum percentage, a reserve percentage, a billing mode of subscription, a calibration switch and a snapshot interval. The default maximum is 75 percent, which means the tool will not spend more than three quarters of the available allowance in a run, and the reserve percentage of 5 keeps a slice back.

The CLI exposes the budget as a first class object rather than a hidden setting. There is nightshift budget for the current status, nightshift budget --provider claude to scope it to one provider, nightshift budget snapshot --local-only for a local snapshot, nightshift budget history -n 10 for the recent history, and nightshift budget calibrate to run the calibration. The run command itself has a matching escape hatch, an --ignore-budget flag, and the documentation is careful to mark it as one to use with caution.

The calibration is the interesting part, and the Makefile has a dedicated target for it. The provider-calibration command compares providers against a repository, taking a repo path, a codex originator of codex_cli_rs, and a minimum number of user turns of 2. In other words, the tool can measure how a provider actually performs on your code, rather than assuming one model is better than another for your repository, and it can then use that to decide where to spend the budget.

There is a snapshot interval of 30 minutes in the example, which suggests the budget tracking is periodic rather than per request, and that a run can overshoot slightly between snapshots. The other cost-related commands are the task listing filters, nightshift task list --cost low --json, which lets you see which tasks are cheap before you queue them, and the cost tiers in the filter list, low, medium, high and veryhigh.

For a user on a subscription, this is the part that makes the tool safe to leave running, and it is the part to configure first.

Installing it and the first commands to run

There are three installation routes, and they are all one line each.

The Homebrew tap is the primary one:

brew install marcus/tap/nightshift

Binary downloads are available on the GitHub releases page, and the manual route is a go install of the command:

go install github.com/marcus/nightshift/cmd/nightshift@latest

After installation, the guided setup walks you through provider configuration, project selection, budget calibration and daemon setup:

nightshift setup

That step is where the global configuration file is created or updated, at ~/.config/nightshift/config.yaml, and it is the moment to decide the budget limits and the permission flags rather than accepting the examples.

Before letting it run, the readme suggests previewing what it would do and looking at the budget:

nightshift preview
nightshift budget

And to start a run immediately rather than waiting for the schedule:

nightshift run

The preview command is the interesting one, because it shows the prompts rather than running them. The flags give you a few different views: -n 3 to see the next three scheduled runs with prompt previews, --long, --explain, --plain, --json for machine consumption, and --write to dump the prompts to a directory. If gum is available on the machine, the preview output is shown through the gum pager, and --plain disables that.

The remaining commands cover the rest of the surface. There is nightshift doctor for checking the environment and config health, and nightshift status --today for today's activity summary. The task commands list what is available, nightshift task list with filters such as --category pr or --cost low, show details and the planning prompt with nightshift task show lint-fix, and run one immediately with nightshift task run lint-fix --provider claude, including a --dry-run form and a --prompt-only form for piping.

Preflight, confirmation and the flags that change the blast radius

Before executing anything, the run command displays a preflight summary showing the selected provider, the budget status, the projects and the planned tasks. In interactive terminals you are prompted for confirmation, and in non-TTY environments such as cron, the daemon or CI, the confirmation is skipped automatically.

That last detail is a real design consideration for a tool whose whole point is unattended operation, and it also means the guard rail behaves differently depending on where it runs. If you want the prompt even in a non-interactive context, the --yes flag skips it and the absence of it does not restore it.

The flags table is where the scale of a run is set. --dry-run shows the preflight and exits. --project and --task target one project or one task, and they override the limits below. --max-projects defaults to 1 and --max-tasks defaults to 1, so the default run is a single project and a single task, and the flags are ignored when a specific project or task is named. --random-task picks a random eligible task instead of the highest scored one, which is a deliberate way to stop the tool from doing the same thing every night. --ignore-budget bypasses the budget checks and shows a warning. --yes skips the confirmation prompt.

Other flags refine the behaviour: --category filters by task category, with the categories being pr, analysis, options, safe, map and emergency, and --cost filters by cost tier. The --timeout sets an execution timeout with a default of 30 minutes, which is the bound on a single agent invocation.

The task categories are worth a second look, because the naming describes the risk model. A category named emergency alongside safe, and options alongside analysis, tells you that the tool has a notion of how dangerous a change is, and the emergency category in particular suggests tasks that should be treated as exceptional rather than routine.

Three provider CLIs and the authentication each one needs

Nightshift supports three AI providers, and in every case it drives an existing local command line tool rather than calling an API directly.

Claude Code is Anthropic's Claude via the local CLI, and authentication is done with the claude command followed by the login command. It supports Claude.ai subscriptions or Anthropic Console credentials. Codex is OpenAI's GPT via the local CLI, authenticated with codex --login, and it supports signing in with ChatGPT or with an API key. GitHub Copilot is GitHub's Copilot via the GitHub CLI, which needs the CLI installed, either through npm with a global install of the package, or through the install script, and it requires a GitHub Copilot subscription. There is a separate document for the Copilot integration.

If you would rather use API based usage, you can authenticate the Claude and Codex CLIs with API keys instead, which matters for a user on a metered API plan rather than a subscription.

The design choice here is the one that makes the tool work with the subscription model: the budget is measured against the subscription allowance, and the allowance belongs to the CLI, not to Nightshift. Driving the local CLI means Nightshift inherits the provider's own session state, its own data directory and its own pricing model.

It also means Nightshift is only as good as the CLI version you have installed, and that a provider upgrade can change the behaviour of an unattended run. The calibration command exists precisely to notice that, by measuring providers against a repository rather than assuming.

The repository contains a .claude/ directory and both an AGENTS.md and a CODEX.md at the root, which means the project has been set up to be worked on by either of those agents, and the top of the readme asks you to check whether you are running inside Sidecar and to run a command to see the capabilities available in that environment.

The engineering behind the tool

The Go module tells you what the tool is made of. The interface layer is the Charm libraries, bubbletea, bubbles and lipgloss, with termenv and go-isatty underneath, so the CLI is a terminal user interface in the modern Go style rather than a set of printed lines. The command structure is cobra with viper for configuration. Scheduling is robfig/cron, so the cron expression in the configuration is a first class part of the design. Logging is zerolog, file watching is fsnotify, and the state is kept in a database with modernc.org/sqlite, which is the pure Go SQLite implementation, so the tool has no cgo dependency.

The Makefile shows the development workflow. There are targets for build, install, test, a verbose test, a race test, coverage with an HTML report, a lint target that requires golangci-lint, a deps target that runs go mod download and go mod tidy, a check target that runs test and lint together, and the provider calibration target. There is also an install-hooks target, which is consistent with the repository carrying a .claude/ directory.

The packaging is handled with goreleaser, and the distribution is a Homebrew tap plus the GitHub releases page, with a go install path as the third option.

The rest of the repository is a documentation project as much as a code project. There is a docs/ directory with the installation, quick start, CLI reference, configuration, budget, scheduling and tasks guides, a SPEC.md for the detailed options, a website/ directory matching the documentation site, a scripts/ directory, a CHANGELOG.md, a SECURITY_AUDIT.md, and a .plan/ directory.

The release history is small and recent. The tags are v0.3.2 on 2026-02-17, v0.3.3 on 2026-02-19 and v0.3.4 on 2026-02-28, and the last push was on 2026-10-01 with the repository not archived, so the source is moving well ahead of the last published release.

Editorial conclusion

Nightshift suits an individual developer with a generous subscription allowance and a habit of reviewing pull requests, and it suits a team that wants the chores of stale documentation and dead code handled overnight without anyone spending attention on them. It is the wrong choice if you do not review pull requests carefully, because the tool's entire safety story is that a bad change is a pull request you close, and it is a poor match for a repository where an autonomous agent must not push branches or run commands. Before adopting, read the provider section of the configuration and turn off the permission skipping it enables, set the budget maximum below the default 75% until you trust the results, and run the preview and dry-run paths first.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. marcus/nightshift on GitHub
4. README
5. Releases