K1.7.1 Task 1.7

Resume Saves 44% Time and 58% Tokens in CI Pipelines

Claude Code sessions persist and can be resumed. For interactive use, --continue resumes the most recent session. For CI/CD automation, capture session_id from JSON output and use --resume with the explicit ID — because --continue is unsafe with concurrent pipelines.

Interactive: —continue

claude --continue resumes the most recent session. Combined with -p: claude -p "continue the auth review" --continue. Simple, no ID needed.

Programmatic: —output-format json + —resume

For automation scripts and CI/CD:

  1. Stage 1: claude -p "lint check" --output-format json → parse session_id from JSON response
  2. Stage 2: claude -p "review code" --resume $SESSION_ID

The --output-format json flag produces structured output with session_id that can be reliably parsed with tools like jq. Pass the ID between pipeline stages via environment variables.

The pipeline data

Comparing fresh sessions vs resume chains for a 3-stage CI pipeline:

MetricFresh sessions (per stage)Resume chain
Stage 145 sec, 12,000 tokens45 sec, 12,000 tokens
Stage 245 sec, 12,000 tokens18 sec, 3,000 tokens
Stage 345 sec, 12,000 tokens12 sec, 2,000 tokens
Total135 sec, 36,000 tokens75 sec, 17,000 tokens

44% time reduction, 58% token reduction, identical quality. Resumed stages don’t re-read files already in context.

Session state is LOCAL

Session data is stored on the machine where it was created. If a CI runner allocates stage 2 to a different machine than stage 1, the session_id points to data that doesn’t exist on that machine. The resume silently fails, behaving as a fresh session.

Fix: ensure pipeline stages run on the same machine, or use a shared session storage mechanism.

—continue is unsafe for concurrent pipelines

--continue resumes the MOST RECENT session globally on the machine. With concurrent PR pipelines:

  • PR-1 stage 1 completes at 10:00:01
  • PR-2 stage 1 completes at 10:00:02
  • PR-1 stage 2 uses --continue → resumes PR-2’s session (wrong!)

Fix: always use --resume $SESSION_ID in automation. --continue is safe only for single-user interactive use.

Robust multi-PR pipeline strategy

For concurrent multi-PR pipelines on shared CI runners:

  1. Each PR’s stage 1 captures session_id from JSON output
  2. session_id is passed as a pipeline variable to subsequent stages
  3. Each stage uses --resume $SESSION_ID with the PR-specific ID
  4. Per-PR session isolation is guaranteed regardless of concurrency

Sequential reviewers building on prior work

Two reviewers working on the same PR at different times: reviewer 1 captures session_id, reviewer 2 uses --resume to start with reviewer 1’s complete context — all files read, findings identified, reasoning preserved. No redundant file reading.

The anti-pattern: fresh sessions for every stage

Starting fresh sessions for each pipeline stage discards all accumulated context. The review stage loses lint findings. Test generation loses both lint and review insights. Each stage re-reads the same files. 135 seconds instead of 75. 36,000 tokens instead of 17,000.


One-liner: Use --continue for interactive resume and --resume $SESSION_ID (captured via --output-format json) for CI/CD — resume saves 44% time and 58% tokens, but session state is local and --continue is unsafe for concurrent pipelines.