tmux · plain files · zero infrastructure

Let My Agent Sleep

AI agents start long-running jobs, stop waiting, and resume a supported session when the job finishes. No polling. No token burn from waiting.

$ npx let-my-agent-sleep install

Star on GitHub View on npm

● Handles 17-hour training runs end to end · requires tmux · MIT

agent session

tokens over a 24-hour wait 1.93B → 387K ~4,980× fewer

24h of polling $382

→

LMAS lifecycle $0.18

×2,125 cheaperobserved rate

LMAS doesn't make the wake-up free. It makes the waiting disappear.

Measured polling rate ($2.72 / 10.2 min) projected over a 24-hour wait, vs the measured LMAS handoff + completion for a real run. The LMAS cost doesn't grow with wait time.

Kimi uses an observed OpenCode polling rate; other rows use model list pricing, standard context tier, July 2026.

The problem

Waiting is the expensive part.

A long job doesn't need a babysitter. But most agents don't know that — so they sit there and spend.

Without LMAS

Your agent burned tokens all night checking a log

It kicked off a 12-hour training run, then read the same log every 10 seconds until morning. Thousands of checks, zero new information — and you paid for every one. That's where LMAS was born.

≈ 4,320 log checks · 0 useful work between them

With LMAS

One handoff, one wake-up

The agent starts the job and goes quiet. Hours or days later — the moment the job ends — the supported session wakes with the result and full context, and keeps working.

1 handoff · 1 wake-up · the agent designs the next run

In practice

What a research loop looks like.

When a run fails, the agent wakes, fixes, and relaunches. When it succeeds — even 20 hours later — the supported session picks up and continues.

Day 1

17:11 HANDOFF

Agent launches smoke training via lmas_start

python -u training/train.py -c configs/qat/exp_b.yaml — handoff returned, session sleeps.

17:12 FAILED

Completion event: exit_code 1 — the failure wakes the agent immediately

It reads stderr.log, finds a bad config path, fixes it, and relaunches. Turnaround: ~1 minute.

18:54 FAILED

Full training fails fast

Woken again in seconds, the agent finds and fixes the bug.

18:55 HANDOFF

Relaunch — session sleeps

One minute from failure to a fixed, running job.

20.5 hours pass — overnight and into the next afternoon.

Day 2

15:30 SUCCEEDED

LMAS_COMPLETION_EVENT wakes the original session

Same session, full context intact.

15:31 HANDOFF

Agent inspects the logs and launches the full evaluation itself

The loop continues.

Day 1

17:11 LAUNCH

Agent launches training with nohup

nohup python -u training/train.py -c configs/qat/exp_a.yaml > train.log & — and now it has to stay awake.

17:21 CHECK

First check

sleep 10 && tail -n 5 train.log — "step 4/4000". Still running. Check again.

17:31 CHECK

Same check, same answer

Another log dump into the context. Nothing new learned.

17:41 → next day × 121 CHECKS

× 121 checks over 20.6 hours

Every check re-reads the log and reloads the whole session context. The transcript bloats with log dumps; the agent learns nothing between checks.

Day 2

next morning CRASH FOUND

A human discovers the run died overnight

Nobody was awake to see it fail. The fix waits for office hours — and the session context is too bloated to keep working in.

Failures wake you too.

A crashed run wakes the agent in seconds — not discovered dead the next morning.

turnaround: 1 minute

The agent designs the next step itself.

Five runs in one session — smoke → eval → full → relaunch → full eval — with no scheduler and no job chaining. Each completion event is just a prompt; the agent decides what's next.

5 runs · 0 scheduled jobs

One session, zero polling.

The whole multi-day loop runs in a single session — no restarts, no re-priming.

1 session · ~22 hours wall clock

Why LMAS

What you actually get.

Survives everything

Close the app, compact the context, run for days — the job and the wake-up outlive the agent.

Crashes get fixed in minutes

A failed run wakes the agent immediately — not found dead the next morning.

Zero polling burn

No polling loop, no "continue" spam. The session sleeps until there's something worth waking for.

Nothing to run

bash + tmux and plain files. No LMAS daemon, no cloud, no database.

And two things it will never do: kill your job with a timeout, or decide your next run for you.

Adapters

Works with your agent.

OpenCode

Primary

Full plugin, server-backed wake-up.

Codex

Supported

Automatic same-session resume.

Claude Code

Experimental

Resume when available; prompt fallback.

FAQ

Why not just use nohup?

nohup keeps the process alive. LMAS also records a handoff, watches completion, and wakes a supported agent session with the stdout, stderr, metadata, and artifact paths it needs to continue.

Does LMAS make completion free?

No. The wake-up prompt still costs tokens. LMAS removes the waiting portion: the log polling, repeated continues, and context reloads while the job is still running.

Do I need to change my training code?

No. The agent wraps your existing command with LMAS. Your script still runs as the same command, in the same working directory, with stdout and stderr captured.

What does it require?

tmux must be installed. LMAS itself has no daemon, database, cloud scheduler, or project-specific callback. OpenCode wake-up still needs the owning OpenCode server/session alive at completion.