A while ago I wrote about a problem I kept hitting with Claude Code: I could give it a large task, walk away, and come back later to find that it had stopped somewhere in the middle.
That problem is what originally pushed me to build Nightshift.
At first, the goal was mostly:
How do I keep the agent working?
Once I got the agent to reliably work for hours, my focus shifted.
The problem was no longer just keeping it alive. I started focusing on improving the shift itself:
If I leave a coding agent working for several hours, how do I make that run something I can actually understand, trust, review, recover, and keep as history afterward?
That changed how I think about long-running agent work.
I don't really want a six-hour conversation.
I want a shift.
The shift should exist outside the chat
The core idea in Nightshift is:
The work contract and run state live on disk, not only in the conversation.
During a shift, I want to be able to open the files and see:
- what is done
- what is being worked on now
- what is still open
- what is parked or blocked
- what decisions were made
- what was tried and rejected
- what still needs verification
The conversation is still useful for instructions, reasoning, and following the work as it happens. But for a multi-hour shift, I don’t want it to be the only place that remembers what was agreed, what changed, what failed, and what is still left.
That becomes especially important when context gets compacted, a session fails, or I come back the next morning and need to understand what happened without scrolling through one giant chat.
Two kinds of shifts
Nightshift currently supports two main ways of working.
1. Planned shifts
You define the work up front as a concrete feature plan.
For example:
- [ ] build the Products module
- [ ] add product categories
- [ ] add coupons and discount rules
- [ ] add inventory tracking
- [ ] add product search and filters
- [ ] audit the whole module end-to-end and make sure every backend flow has the required UI and works correctly
- [ ] add tests and verification
Each item can have its own quality or verification requirements, and/Or you can also define checks that apply to the whole shift.
The shift keeps working until every contracted item is ticked off. Owner-defined quality checks describe what “done” should mean, but the model decides when an item is ready to tick. Nightshift tracks that state and mechanically prevents the model from clocking out while anything is still open. Whether the work is actually good enough is still for the human reviewer to decide.
2. Open-ended shifts
This mode became one of my favorite parts of Nightshift.
Instead of giving it a fixed checklist, I give it:
a goal + a strict time budget
For example:
Improve this product for the next four hours.
The agent can inspect the product, codebase, history, tests, existing issues, comparable approaches, technical debt, UX problems, or other useful opportunities.
It finds useful work, ranks it, works on the strongest opportunities, and then keeps going.
If it finishes one thing early and tries to stop while meaningful time is still left, the shift pushes it to continue exploring and improving until the time budget is actually over.
The stopping condition becomes less:
"The model feels finished."
and more:
"The shift is over."
A side effect I ended up liking a lot
This created a use case I didn't originally build Nightshift for.
Sometimes my Claude, Codex, or Cursor usage is going to reset the next day, and I still have a chunk of allowance left.
Maybe I don't have a feature prepared.
Maybe nothing is currently planned on the timeline.
Maybe I just have a few hours of usage that are going to disappear anyway.
Instead of wasting that capacity, I can start an open-ended shift and say:
You have three hours. Find useful work and improve the project.
Nightshift keeps the model working within that time budget instead of letting it finish one small task and stop after 20 minutes.
So the ready-made and open-ended shifts also give me a way to spend otherwise-expiring usage usefully when I don't already have anything planned.
Ready-made shifts
You don't always need to design the shift yourself.
Nightshift also has a catalog of reusable shifts for things like:
- defect hunting
- test coverage
- quality debt
- dependency upgrades
- codebase review
- Product Evolution
For example, Product Evolution is an open-ended shift that studies the product, its history, user needs, and relevant standards, ranks opportunities by evidence, value, effort, reversibility, and risk, then works on the strongest ones within the available time.
The catalog is useful when I know I want to spend a few hours of agent time productively but don't have a detailed backlog ready.
Longer term, I want this catalog to grow beyond my own workflows.
If someone has a long-running workflow that consistently works well, it should be possible to turn that into a reusable shift that other people can install, customize, and contribute back.
And I don't think those shifts necessarily need to be coding-only.
Recurring workflows like SEO, research, audits, or other reviewable agent work can fit the same model too.
I didn't want to build another agent runtime
This became an important design decision as Nightshift grew.
I don't want Nightshift to replace Claude Code, Codex, or Cursor.
Those tools already have their own ecosystems, commands, skills, hooks, capabilities, and ways of working.
Nightshift is designed to augment those ecosystems, not sit in front of them as another agent platform.
There is no Nightshift cloud service or account.
You don't need another npm CLI or Homebrew-installed orchestration runtime that proxies the agent.
Claude Code should still feel like Claude Code.
Codex should still feel like Codex.
Cursor should still feel like Cursor.
Nightshift adds the shift contract, state, enforcement, recovery, review, and archive layer around them.
Long-running doesn't just mean "keep looping"
There are already good ideas for keeping agents working for a long time.
Ralph-style loops, for example, already established patterns around persistent plans, specs, repeated iterations, and state that survives outside a single chat.
So Nightshift isn't trying to claim that file-backed plans or long-running loops are new.
The part I'm interested in is the accountability around the run:
- what exactly was contracted
- what is still unfinished
- what quality bar applies
- what decisions were made
- what got blocked
- what failed
- what was verified
- whether the session died
- how it recovered
- what evidence exists afterward
Keeping an agent running for six hours is useful.
Being able to understand what actually happened during those six hours is much more useful.
Recovery should survive the agent itself
Another part I didn't want to trust only to prompting was recovery.
If the process doing the work is also the only thing responsible for noticing that it died, that isn't very helpful.
Nightshift therefore has an external watchman.
For example, if a Claude Code session hits a structured API failure such as:
API Error: 500
the watchman can keep attempting to recover the recorded conversation when the API becomes available again.
For Codex, the watchman can recover a session once it is proven dead, preferring the recorded session when its identity is resumable. If that isn't possible, the on-disk contract still provides the handoff for a fresh recovery.
Failures will happen.
The goal isn't to pretend they won't.
The goal is that a temporary API or session failure doesn't silently throw away the remaining hours of work.
The shift doesn't disappear when it ends
This is one of the parts I appreciate more the longer I use Nightshift.
When I want to file away finished work, Nightshift can archive the completed part of the shift.
Nightshift moves completed items, handled snags, and the rotated journal into a dated archive. Receipts are copied into the dated archive too, while the live copies stay in place.
The active contract and any still-open work stay intact instead of being filed away as if they were finished.
Over time, those dated archives become a much cleaner history of previous shifts.
The original conversation might be thousands of lines long, but the archive gives me a short, structured record of what was completed, what decisions were made, what went wrong, and what evidence was left behind.
So instead of reopening an old marathon chat and trying to reconstruct what happened, I can open the archive for that date and understand the shift much faster.
Even a shift I decide not to merge can leave useful history.
Maybe the implementation wasn't good enough, but the investigation found something important.
Maybe an approach failed, and I don't want the next agent rediscovering the same dead end.
Maybe a decision needs to be revisited later.
That history is worth keeping.
Read the receipts, not the promise
The direction I'm pushing Nightshift toward is pretty simple.
I don't want the final handoff to just be:
"Done! Everything looks good."
I want to be able to inspect the actual state, diff, commits, verification, decisions, failures, and receipts myself.
Long-running autonomy becomes easier to trust when you don't have to trust the agent's summary of its own work.
Read the receipts, not the promise.
Where Nightshift is now
Nightshift is open source under MIT and currently supports:
- Claude Code
- OpenAI Codex
- Cursor
It runs locally and is designed to augment those tools rather than replace them.
The project is still evolving, especially around reusable shifts, stronger review workflows, and making the same model useful beyond coding.
But the basic idea has become pretty clear to me:
Give the agent a real shift instead of one enormous chat.
Define the work or the time budget.
Keep the state outside the conversation.
Keep it working while the shift is active.
Recover when things fail.
Keep the evidence.
Archive the result.
Then review what actually happened.
Nightshift
If you're already leaving coding agents working unattended for hours, I'd be especially interested in the workflows you've found that consistently work well.
Some of them might make good reusable Nightshift shifts.
Top comments (0)