Bonus: Continuous Work Across Session Windows — The Methodology

The Problem

The 5-hour session window is a hard limit. When it fills, work stops. A new session starts with zero context carry-over (except what’s in memory files and git history). Large tasks that naturally take 8, 12, or 20 hours get interrupted at arbitrary points.

The question: how do you structure work so interruptions don’t reset progress?

The Core Constraint: I Cannot See Usage

First, the honest constraint: I cannot see your usage meter. From inside a session, I have no API access to usage data. You see the percentage in the UI; I don’t.

This means:

• I can’t automatically detect when the window is filling
• I can’t trigger checkpoints based on actual usage
• I can’t decide when to save state — you must tell me, or we use a fixed schedule
• Your awareness of the usage clock is part of the coordination mechanism

This isn’t a design flaw. It’s a boundary: compute limits are enforced by the system, observable by the user, and I can only respect them if you communicate them.

The Checkpoint Pattern

Instead of context carry-over (impossible), we use explicit hand-offs. At the session boundary, a checkpoint file captures:

# Session Checkpoint — Task: [task name]

## Current Status
- Branch: [git branch]
- Last commit: [hash] [message]
- Uncommitted changes: [summary or git status snippet]

## What Was Done This Session
- [Major accomplishment 1]
- [Major accomplishment 2]
- [Blockers if any]

## What's Next (Exact Next Steps)
1. [Specific action with file paths]
2. [Specific action with file paths]
3. ...

## Context for Next Session
- [Any non-obvious state]
- [Decisions made and why]
- [Files to read if confused: MEMORY.md, CLAUDE.md, specific docs]

## Resume Prompt

[Copy-paste this to start the next session] /loop Continue the [task name] work:

[Exact task description for next iteration]

The checkpoint goes in .claude/SESSION_CHECKPOINT.md and is committed to git. Next session reads it, proceeds without re-reading the full codebase.

Three Approaches

Approach 1: Manual Checkpointing with /loop

How it works:

1. You run: /loop Continue work on [task]
2. I work for 4-5 hours
3. Before the window fills, you say: “checkpoint now”
4. I save .claude/SESSION_CHECKPOINT.md and use ScheduleWakeup to auto-resume after the window resets (~10 minutes)
5. Next iteration: I read the checkpoint and continue from the exact stopping point

Coordination:

• You glance at usage meter occasionally (not continuously)
• When you see session hitting 80%+, tell me “checkpoint”
• I handle the save and resumption

Pros:

• Works today with existing tools
• You maintain awareness but don’t micromanage
• Can adapt if a session finishes early or runs long
• Transparent — you see when restarts happen

Cons:

• Requires your attention (albeit minimal)
• Manual timing, not automated

Approach 2: Fixed-Interval Checkpointing with /loop

How it works:

1. You run: /loop Continue work on [task]
2. I work for 4 hours 50 minutes, then checkpoint automatically
3. I use ScheduleWakeup to resume after the window resets
4. Repeat until task completes

Coordination:

• No interaction needed after /loop starts
• I assume each window is ~4h 50m and checkpoint at that mark
• Works for tasks that naturally fit in iterations

Pros:

• Fully automatic after starting
• No need to watch the meter

Cons:

• If a session finishes early, time is wasted
• If a session needs more than 4h 50m, it gets interrupted
• Less flexible for variable-length work

Approach 3: Hybrid with External Monitoring

How it works:

1. A shell script prints current usage % every few minutes
2. You run /loop and let the script run alongside
3. Script alerts you when session hits threshold
4. You tell me “checkpoint” when ready
5. I save and resume

Coordination:

• Same as Approach 1 but with automated alerts instead of you checking manually
• The script doesn’t interrupt me; it just notifies you

Pros:

• Automation on your side (the script)
• I still get the explicit signal to checkpoint
• Combines automation with human judgment

Cons:

• Requires a monitoring script
• Still requires your approval to checkpoint

The ScheduleWakeup Mechanism

Within a /loop context, I can use ScheduleWakeup(delaySeconds, reason, prompt) to schedule the next iteration.

How it works in practice:

Session 1 (0-4h 50m):
  - Work on task
  - At 4h 45m: save checkpoint
  - ScheduleWakeup(600, "session window reset", "/loop Continue...")
  - Session ends

[Window resets in ~10 minutes]

Session 2 (auto-resumed):
  - Wake up, read checkpoint
  - Continue from exact stopping point
  - Work for another 4h 50m
  - ScheduleWakeup again

The prompt passed to ScheduleWakeup is crucial — it must be complete enough for a cold start:

/loop Continue implementing ExtKit Phase 3:

[Full context: what's built, what's being worked on, what's blocked]

What the Checkpoint Captures

Essential:

• Current git state (branch, last commit, uncommitted changes)
• Exact stopping point (line numbers, what file, what needs to happen next)
• What was completed this session (quick summary)
• What’s blocked, if anything

Context (for readability):

• Key decisions made and why
• Files that matter for the next session
• Links to memory.md or phase specs if relevant
• Any non-obvious state (environment setup, temporary files, etc.)

The resume prompt:

• Verbatim copy-paste of what to run next
• Should be complete enough to start a new session without reading the checkpoint again

Managing Memory Across Boundaries

The checkpoint is the immediate handoff. But memory files (MEMORY.md, project-specific memory) are the long-term context.

Before each checkpoint:

• Update project MEMORY.md with new status
• Update global MEMORY.md if scope changed
• Add any new architectural decisions to memory

On resume:

• I read MEMORY.md first (existing pattern)
• Read the checkpoint second
• Read the code third if needed

This keeps memory current so each session starts with fresh state, not stale summaries.

Exit Criteria: When to Stop Checkpointing

Not every task needs this. Use checkpoints when:

• Task spans > 1 session — if it needs 8+ hours
• Work is complex — multiple files, architectural decisions
• Progress is non-linear — early sessions are exploration, later ones are implementation

Don’t checkpoint for:

• Short tasks (< 1 session)
• Simple fixes (single file, obvious solution)
• Reading/research (no work state to save)

The Full Workflow: An Example

Task: Implement ExtKit Phase 3 (Messaging)

Session 1:

/loop Implement ExtKit Phase 3 (messaging):

Read phase3-spec.md, build MockRuntime stubs for messaging,
write test file for context-transparent routing, implement core
messaging dispatch logic.

Exit when: 15 passing tests, MockRuntime has all stubs, 
basic routing works.

Work for ~4h 50m:

• Read the spec
• Build MockRuntime stubs
• Write 10 tests
• Implement basic routing
• ~8 tests passing (blocked on context detection edge case)

At 4h 45m:

• Checkpoint to .claude/SESSION_CHECKPOINT.md:

  Branch: phase-3-messaging
  Tests: 8/15 passing
    
  What's done:
  - MockRuntime stubs for messaging API
  - Test file skeleton with 15 test cases
  - Basic message routing dispatch
    
  What's next:
  - Fix context detection edge case (line 87 in messaging.js)
  - Add 7 more tests for routing correctness
  - Implement the "context-transparent" routing logic that
    detects background vs content vs popup context
    
  Resume prompt:
  /loop Continue ExtKit Phase 3 (messaging):
    
  Context: 8/15 tests passing. Blocked on context detection
  in messaging.js line 87 — getContext() returns undefined
  in popup context. Need to verify context detection logic
  in core/context.js is exported correctly.
    
  Next: fix the context detection, get remaining 7 tests passing,
  exit when 15/15 pass and basic routing works.
  

• Use ScheduleWakeup(600, "session reset", "/loop Continue ExtKit Phase 3...")
• Session ends

~10 minutes later, window resets:

Session 2:

• Auto-resume with the checkpoint
• Read checkpoint (2 min)
• Open messaging.js line 87
• See the issue: getContext() returns undefined
• Check context.js — ah, detectContext is not exported
• Fix the export, run tests
• 10 tests passing now
• Work on the remaining 5 tests
• Get to 15/15 passing at 4h 40m
• Commit changes
• Update MEMORY.md with “Phase 3: Messaging — ✅ Complete”
• No more checkpoints needed — task done

When Things Go Wrong

What if a session finishes early?

• You’ve already paid for the window
• Use the remaining time for next task or cleanup
• Or just end — it’s fine to not max out every session

What if I misunderstand the checkpoint?

• The checkpoint is a contract, not a guarantee
• If something’s unclear, I ask in the next session
• The resume prompt can include “if unsure, read MEMORY.md and the phase spec”

What if the work is more complex than expected?

• Checkpoint more frequently (every 3-4 hours instead of 4h 50m)
• Or extend the checkpoint with more detail
• The pattern is flexible — adjust based on actual needs

Why This Matters

Without this pattern, a large task is:

• Interrupted by window resets
• Requires full context re-read each session
• Wastes time re-discovering state
• Accumulates technical debt as shortcuts get taken

With the checkpoint pattern:

• Interruptions are scheduled, not chaotic
• Next session reads one file, not the whole codebase
• Progress is continuous even across window boundaries
• Work quality stays high because context is preserved

Implementation Readiness

Everything needed to run this exists today:

• ScheduleWakeup — built into Claude Code
• /loop — already available
• Git + .claude/ directory — already available
• MEMORY.md pattern — already in use

No new tools need to be built. The methodology is about organizing existing tools.

This bonus essay outlines the methodology. Decide if it fits your workflow, and let me know if you want to set it up.