Detailed Analysis
A Reddit user's account of a malfunctioning Claude Scheduled Task highlights a significant reliability gap in Anthropic's automation feature, one that consumed hours of usage allowance without producing any useful output. The user had configured a simple daily task—refreshing a personal dashboard by pulling data from Gmail and Calendar—running on Opus. Because those integrations were approval-gated and no one was present to authorize access at 7:31 AM, the task could never actually complete its intended function. Notably, the model itself behaved correctly in isolation: it recognized the failure, declined to fabricate data, and explicitly stated the task should be reconfigured with always-allow permissions. The breakdown occurred not in the model's reasoning but in the scheduling harness, which kept re-invoking Opus with the growing transcript every time the task "completed," creating a loop that ran for 8.5 hours despite the model repeatedly declaring it was finished.
The most alarming detail in the report isn't the wasted compute but the claim that the stop button failed to halt execution. If accurate, this points to a disconconnect between the user-facing control layer and the underlying task-execution loop—a failure mode that undermines a basic safety expectation: that users can always interrupt a running process. The subsequent transcript corruption (an empty message triggering cascading "400 Bad Request" errors) suggests the interruption attempt may have left the session in an inconsistent state rather than cleanly terminating it. For a product being positioned for agentic, unattended operation, an unresponsive stop mechanism is a serious usability and trust issue, not merely a cosmetic bug.
This incident sits at the intersection of two trends reshaping how AI companies market and users engage with LLM products: the push toward autonomous, scheduled agents that act without human oversight, and the tension between model-level judgment and system-level orchestration. Anthropic has increasingly emphasized Claude's ability to operate agentically—running tools, executing multi-step tasks, and now firing on schedules without a human in the loop. But this case shows that even when the model correctly identifies a dead end and stops trying, the surrounding infrastructure (schedulers, retry logic, permission gating) can override that judgment and produce runaway resource consumption. It's a reminder that "agentic" reliability depends as much on orchestration engineering as on model intelligence, and that guardrails need to exist at every layer, not just within the model's own reasoning.
The practical costs described—burning through a Max 5x plan's usage window overnight, with no dollar cost but a full session and partial weekly allowance consumed—illustrate why usage transparency and hard runtime caps matter for scheduled or background agent features. The user's suggested fixes are notably modest and achievable: reject task creation when approval-gated tools can't be satisfied autonomously, enforce sane runtime ceilings relative to expected task duration, ensure stop commands are authoritative, and expose clearer usage attribution in run history. As more AI platforms roll out scheduling, background agents, and always-on automation, incidents like this will likely accelerate scrutiny of failure containment and kill-switch reliability, especially as users trust these systems to run unsupervised while they sleep, work, or step away entirely.
Read original article →