Claude Code Background Jobs vs /loop: Understanding Your Options

Claude Code has two fundamentally different execution models. One is interactive—you ask a question, Claude Code works, you watch, you provide feedback. The other is unattended—you describe an outcome, Claude Code works overnight, you review the result in the morning.

These aren't just different in feel. They're different in how the tool behaves, what failure modes exist, and what you can rely on. Understanding which is which, and when to use each one, is the foundation of getting consistent value from Claude Code.

The /loop Command (Interactive Model)

/loop is the Claude Code command for interactive, real-time problem-solving:

You: /loop
Claude Code: Starting interactive session. Type 'done' to exit.
(You interact—provide context, ask questions, iterate)
You: done

How /loop Works

When you run /loop, Claude Code launches a persistent session where:

• You provide context and goals incrementally
• Claude Code executes commands, reads output, and responds in real-time
• You see every step and can course-correct immediately
• The session ends when you say done

Strengths of /loop

Immediate feedback loop. You ask, Claude Code acts, you see the result in seconds. If something goes sideways, you know instantly.

Exploratory work. You're not sure what the right approach is. You try something, see what breaks, adapt. /loop is designed for this.

Debugging. When something fails, you're there to ask follow-up questions. Claude Code doesn't just retry blindly—it has a human in the loop to guide it.

Low risk. If Claude Code misunderstands your request, you catch it before it commits 200 file changes.

Limitations of /loop

Requires your attention. You have to be there, watching, ready to respond. That's the price of interactivity.

Not suitable for long-running work. A 6-hour refactoring job isn't something you'll babysit in real-time.

Session context grows. The longer you keep /loop running, the larger the conversation history, and the slower and more expensive each turn becomes.

No built-in timeout. If Claude Code gets stuck waiting for something (a stalled API call, an unresponsive process), /loop doesn't know. You have to intervene manually.

Background Jobs (Unattended Model)

Background jobs in Claude Code are the opposite of /loop. You define a goal, set it to run unattended, and come back later to check the result:

You: Define goal "upgrade dependencies and run tests"
Claude Code: Job created. Will run at 2am tomorrow.
(You go to sleep)
(Job runs overnight, no interaction)
You: Check results in the morning

How Background Jobs Work

A background job is:

1. A specific goal defined in natural language
2. Optional project scope (which directory or repo to work in)
3. Acceptance criteria (how to know when it's done)
4. A schedule (when to run)
5. Optional run settings (timeout, retry logic, etc.)

When the scheduled time arrives, the job framework:

• Launches Claude Code with the goal
• Redirects input/output to a log file (no interactive terminal)
• Monitors for completion, failure, or timeout
• Records the result with full output

Strengths of Background Jobs

Unattended execution. The whole point. Define it, schedule it, forget about it. You don't have to be there.

Parallelism. Your machine runs a job. You go about your day. Multiple jobs can queue up and run in sequence.

Structured history. Every run is logged with timestamps, exit codes, full output, and cost estimates. You can review results in a dashboard or CLI.

Cost efficiency. Long-running jobs tend to be more cost-efficient when unattended because:

• Claude Code can focus on the goal without context-switching
• Iteration happens without human delays
• Failure recovery (automatic retries) happens in the background

Failure recovery. Some job frameworks (like OpenHelm) support automatic self-correction: if a job fails, run it again with the failure output as context. The second attempt often succeeds because Claude Code now understands what went wrong.

Limitations of Background Jobs

Requires good goal definition. If your goal is vague ("improve the codebase"), you get vague results. In /loop, you'd notice immediately and ask for clarification. With background jobs, you wake up to a mediocre result.

Silent failures. If Claude Code gets stuck (waiting for input, process hangs), a generic background job might not detect it. It just runs until timeout.

Less debuggable. If something goes wrong, you're reading logs instead of having a conversation with Claude Code about what went wrong.

Requires infrastructure. You need something running the job—your machine, a server, a job scheduler. CI/CD platforms add complexity.

Comparison Matrix

The Right Model for Your Task

Use /loop for:

• Exploratory work where you don't know the approach yet
• Debugging and fixing failures in real-time
• Learning how Claude Code behaves
• Single, time-sensitive tasks where speed matters
• Anything where you'll learn from the output mid-process

Use background jobs for:

• Recurring tasks (daily, weekly, on-demand)
• Work you want to happen while you sleep
• Large tasks that would take hours of your attention
• Work with clear acceptance criteria
• Tasks you've already validated with /loop

A Practical Example

Scenario: Refactor the auth module

With /loop:

You type /loop, describe the refactoring goal, Claude Code starts. It reads the auth module, proposes changes, you review them. It modifies files, runs tests, tests fail. You ask why. Claude Code investigates, fixes the issue. Tests pass. You say done. Total time: 45 minutes, all of which you were present for.

With a background job:

You define the goal "refactor auth module to use the new session API. Acceptance criteria: all tests pass, no breaking changes to the public interface." Schedule it for 2am. Wake up. The refactor is done, tests are passing, or you have a log explaining what went wrong and where it got stuck. Total time: 5 minutes of your time to define the goal. The rest happened while you slept.

The Honest Assessment

/loop is more intuitive. It's how you'd work with a developer sitting next to you. Background jobs require more discipline—you have to specify goals clearly, accept that you won't be there when things go wrong, and trust the framework.

The developers who get the most from Claude Code have learned to use both: /loop for exploration and debugging, background jobs for the mechanical work that's well-understood. That combination is where the real productivity gains happen.