Anthropic’s subscription model allows for significant cost savings if you can decouple interactive usage from background automation. A new guide on DEV.to by user deadcatfound details how to run Claude Code as a persistent background worker on macOS, effectively turning a personal subscription into a low-cost inference engine. The author operates an AI trading desk with eight agents and scheduled jobs running around the clock on a Mac Mini, leveraging the non-interactive mode of Claude Code to avoid API key costs entirely.

The Non-Interactive Loop Architecture

The core mechanism relies on claude -p "prompt", which executes a single turn and exits. The author wraps this command in a bash loop that monitors an inbox directory for text files. When a file appears, the script reads the prompt, executes Claude Code, and writes the output to a 'done' directory before deleting the source file. This file-based queue is simple but robust, allowing for easy swapping of the trigger mechanism later. However, the guide emphasizes that this only works if the underlying authentication session is valid and active.

Launchd and the Silent Killer: PATH

To keep the worker alive across reboots and crashes, the setup uses macOS launchd via a custom .plist configuration. This is where most engineers stumble. The guide highlights that launchd starts scripts with a bare environment, often resulting in claude: command not found errors. You must explicitly define the PATH in the plist to include directories like /opt/homebrew/bin or ~/.local/bin. Furthermore, the script must be configured to retry failed jobs rather than deleting them, ensuring that transient errors don’t result in data loss.

Authentication Expiry and Usage Caps

The most critical failure modes are authentication expiry and confusing usage caps. Background runs cannot interactively handle login prompts, so if the session token expires, the worker fails silently with 401 errors. The author recommends a separate hourly health check using claude -p "say OK" to trigger alerts. Crucially, the guide distinguishes between 'session limits' and 'weekly limits'. The author notes that their setup fired "auth failing" alarms for four hours one afternoon when they had only hit the session cap. This highlights the importance of reading error messages carefully: a session cap hit is not the same as an auth expiry, but both stop the worker. Additionally, subscription limits are shared between interactive and background use. The guide warns that agents can easily consume weekly limits by queuing follow-up tasks. In one instance, a runaway loop consumed 11% of the weekly allowance in a single day because jobs were recursively spawning new work.

Key Takeaways

  • For desktops, set sleep to 'Never' in System Settings or run the worker under caffeinate -s; for laptops, caffeinate is insufficient if the lid is closed unless plugged into power and an external display.
  • Explicitly set the PATH in your launchd plist to avoid command-not-found errors.
  • Distinguish between session caps and auth expiry when debugging; hit session caps may trigger false auth alarms, requiring careful error parsing.
  • Implement a health check for auth expiry, as background processes cannot re-login, and guard against recursive job creation to avoid burning through weekly limits.

The Bottom Line

This approach is a clever hack for hobbyists, but it is brittle for production. Relying on personal subscription limits for automated agents introduces unacceptable risks of silent failures and rate limit exhaustion. For serious infrastructure, API keys remain the only reliable path.