Research scheduling in Claude Code: capabilities, costs, use cases

Goal

Understand how Claude Code's scheduling primitives actually work — /schedule (remote cron-based agents), /loop (recurring or self-paced in-session), and the underlying CronCreate tool — and decide which use cases are worth committing to as team standards or new skills.

Current Behavior

We've referenced /schedule and /loop in conversation multiple times but haven't actually used either. Several open questions before we can recommend them confidently:

• Hosting: Where does a scheduled agent run? Anthropic-hosted, local laptop, cloud function?
• Auth & billing: Does it use the Claude Max subscription or require an API key with pay-per-token billing? (See related: GH #100, where the same question came up for the autonomous PR reviewer.)
• Capabilities: Can a scheduled agent push branches, open PRs, post issue comments? What's the permission model?
• State: What persists between runs — file system, conversation context, scratch files in the repo?
• Tool availability: Are MCP servers (ADO, Gmail, etc.) available inside a scheduled run, or only built-in tools?
• Failure handling: What happens when a run errors? Notification? Retry? Silent?
• Mental model: When do you reach for /schedule vs /loop vs CronCreate? Are they layered, or alternatives?

Proposed Solution

1. Read the official Claude Code docs on scheduling primitives — capture the authoritative answers to the questions above.
2. Run one low-stakes experiment end-to-end to learn the lifecycle. Suggested test case: a weekly agent that runs setup-env.sh in dry-run mode and notifies if standards/CLAUDE.md would change anything. Picked because (a) we just discovered standards drifting 5+ weeks unnoticed, and (b) it doesn't push code or touch other systems if it goes wrong.
3. Catalog candidate use cases (initial list below — extend during research).
4. Filter to a shortlist of routines worth standardizing across the team and propose them as separate follow-up issues.

Candidate Use Cases (initial)

Patterns observed in recent sessions where scheduling could help:

Acceptance Criteria

1. A short doc (most likely a new section in standards/CLAUDE.md) describes when to use /schedule vs /loop vs CronCreate, with one concrete example each.
2. At least one real scheduled agent is running against this repo end-to-end (the standards-drift detector or equivalent) — proves the lifecycle works.
3. Authentication, hosting, and billing model is documented unambiguously, including the "do I need an API key?" question that GH #100 also runs into.
4. The candidate use-case table is filtered to a shortlist with a recommendation for each: ship as recurring routine, file as one-off scheduled agent, or skip.
5. Any security concerns (push permissions, secret handling, repo write access from a scheduled context) are surfaced and addressed before any agent that mutates state is scheduled.

Open Questions

• Should this issue be split into research (the doc) + implementation (the first scheduled agent) PRs, per the team standard on phased work?
• Does the answer to "where does a scheduled agent run" overlap with GH #100's hosting decisions for the autonomous PR reviewer? If they share infrastructure, we should align early rather than build twice.

Related

• #100 — first autonomous agent (same hosting/auth/billing questions)
• #86 — local LLM infrastructure (could intersect if scheduled agents become a token-cost concern)

Start with the official Claude Code scheduling documentation and the related decisions in issues #100 and #86. Use setup-env.sh in dry-run mode for the proposed low-stakes experiment, then document the lifecycle, hosting, authentication, billing, permissions, and failure behavior in standards/CLAUDE.md. Done means the three primitives are compared, one scheduled agent runs end-to-end, and candidate use cases and security concerns have recommendations.