[BUG] Cowork Scheduled Tasks can silently consume massive context/cache usage with almost no visible output
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Apparently normal Cowork Scheduled Tasks in Claude Desktop can
generate extremely large amounts of Opus 5 context/cache usage in the
background while producing almost no useful visible output.
I discovered this after unexpectedly reaching my Claude Max usage limit
and subsequently purchasing Extra Usage twice. Both Extra Usage balances
were consumed extremely quickly despite very little useful work being
visibly completed.
I suspected Scheduled Tasks, disabled them, and inspected the local
Claude Desktop / Cowork session metadata and audit.jsonl files on my
Mac.
The local audit data shows repeated automated Scheduled Task sessions
using claude-opus-5 with extremely large cache/context processing
relative to the useful work performed.
One particularly clear example is a Scheduled Task named:
cowork-brain-export
Local session metadata identifies its executions as:
``` text
scheduledTaskId: cowork-brain-export
sessionType: scheduled
model: claude-opus-5
The task had already been decommissioned. Its own instruction explicitly
told Claude that it must perform no work and should only return a short
notice telling me to delete the obsolete Scheduled Task.
The relevant instruction was:
``` text
Dieser Task ist stillgelegt und darf NICHTS tun.
Translation:
``` text
This task is decommissioned and must NOT do anything.
Nevertheless, Cowork continued automatically launching scheduled Opus 5
sessions for it.
My local audit data shows repeated invocations at approximately hourly
intervals. Representative examples from September 10:
----------------------------------------------------------------------------------------
Approx. Scheduled task Model Cache creation Cache read Useful output
local time
---------- --------------------- ---------- -------------- -------------- --------------
08:05 cowork-brain-export Opus 5 \~138k 0 decommission
notice
09:05 cowork-brain-export Opus 5 \~109k \~29k decommission
notice
10:05 cowork-brain-export Opus 5 \~109k \~29k decommission
notice
11:05 cowork-brain-export Opus 5 \~109k \~29k decommission
notice
12:05 cowork-brain-export Opus 5 \~109k \~29k decommission
notice
13:05 cowork-brain-export Opus 5 \~109k \~29k decommission
notice
14:05 cowork-brain-export Opus 5 \~109k \~29k decommission
notice
15:05 cowork-brain-export Opus 5 \~138k 0 decommission
notice
16:05 cowork-brain-export Opus 5 \~109k \~30k decommission
notice
17:05 cowork-brain-export Opus 5 \~109k \~30k decommission
notice
----------------------------------------------------------------------------------------
A separate Scheduled Task (`hd-akquise-briefing`) also launched
automatically using Opus 5 on the same morning. Its local audit data
contains multiple model interactions during a short run and
approximately:
- \~310k cache-creation tokens
- \~844k cache-read tokens
- minimal normal input/output relative to the amount of context
processing
These figures are from my **local Cowork audit records**, not
Anthropic's server-side billing ledger. I therefore do **not** claim
that they independently reconstruct the exact amount billed.
However, they demonstrate the scale of context/cache processing
associated with automated Scheduled Task invocations relative to the
visible work performed.
My current hypothesis is that a large Cowork environment --- system
prompt, tools, skills/plugins, MCP definitions and/or other session
context --- is being loaded or cached before the model can even
determine that the actual scheduled task requires almost no work.
That is a hypothesis, not a confirmed root cause. Anthropic would need
to correlate the local session records with server-side request/billing
telemetry.
This had a direct financial impact once my included Max allowance was
exhausted and paid Extra Usage was enabled: two Extra Usage purchases of
€23.80 each (€47.60 total including German VAT) were consumed
unexpectedly quickly.
I am reporting this as a **Cowork / Scheduled Tasks product and
cost-safety bug**, not asking GitHub maintainers to resolve the billing
dispute.
-----------------------------------------------------------------------
### What Should Happen?
Usage generated by a Scheduled Task should be reasonably related to the
work the task performs and should be visible and controllable by the
user.
A Scheduled Task whose useful output is effectively only:
``` text
This task is decommissioned. Please delete it.
should not silently process approximately 100k+ context/cache tokens per
invocation without making that usage visible.
In particular:
- Scheduled Tasks should expose per-task usage, including model,
input/context, cache creation/read and output.
- Users should be able to set a **per-task usage or spending
ceiling**.
- Scheduled/background tasks should not silently transition into
paid Extra Usage without an explicit user-configurable
permission.
- Users should receive a warning when automated work begins consuming
paid usage.
- Abnormally high context processing relative to useful task work
should trigger an anomaly/runaway safeguard.
- Disabled/decommissioned tasks and their associated sessions should
be clearly visible and reliably stoppable.
Scheduled Tasks are specifically intended for unattended execution, so
they need stronger cost controls than interactive sessions, not weaker
ones.
------------------------------------------------------------------------
Error Messages/Logs
There was no single foreground error message that alerted me to the
problem.
The relevant evidence is in local Cowork session metadata andaudit.jsonl.
Example session metadata:
``` text
scheduledTaskId: cowork-brain-export
sessionType: scheduled
model: claude-opus-5
Representative local audit observations on September 10:
``` text
~08:05 cowork-brain-export ~138k cache creation
~09:05 cowork-brain-export ~109k cache creation + ~29k cache read
~10:05 cowork-brain-export ~109k cache creation + ~29k cache read
~11:05 cowork-brain-export ~109k cache creation + ~29k cache read
~12:05 cowork-brain-export ~109k cache creation + ~29k cache read
~13:05 cowork-brain-export ~109k cache creation + ~29k cache read
~14:05 cowork-brain-export ~109k cache creation + ~29k cache read
~15:05 cowork-brain-export ~138k cache creation
~16:05 cowork-brain-export ~109k cache creation + ~30k cache read
~17:05 cowork-brain-export ~109k cache creation + ~30k cache read
Separate scheduled run:
``` text
Task: hd-akquise-briefing
Model: claude-opus-5
Approx. aggregate local audit usage:
cache creation: ~310k
cache read: ~844k
normal input/output: minimal relative to context/cache processing
I have preserved the original local session metadata, audit logs,
timestamps and session IDs and can provide **sanitized excerpts
privately to Anthropic Engineering**.
I am intentionally not attaching the complete local session directory
publicly because it contains filesystem paths, private task content,
tool/plugin configuration and potentially sensitive information.
------------------------------------------------------------------------
### Error Messages/Logs
```shell
Steps to Reproduce
I do not yet have a minimal deterministic reproduction, so these are
the conditions under which I observed the issue rather than a claim that
every user will reproduce it.
- Use Claude Desktop / Cowork on macOS with a Max subscription.
- Configure a Cowork Scheduled Task to run automatically.
- Have the resulting scheduled session use Opus 5.
- Use a Cowork environment with multiple tools/skills/plugins
available.
- Configure a task that requires almost no useful work. In my observed
case, the task explicitly said it was decommissioned and instructed
Claude to return only a short decommission notice.
- Allow the Scheduled Task to fire automatically.
- Inspect the resulting local Cowork session metadata and
audit.jsonl.
- Compare the actual task output with
cache_creation_input_tokens,
cache_read_input_tokens, input and output usage.
- Repeat across subsequent scheduled invocations.
Observed result
Individual invocations of the near-no-op task recorded approximately
100k--140k cache-creation tokens, sometimes plus approximately
29k--30k cache-read tokens, despite negligible useful output.
User-visible flow
``` text
Scheduled Task fires
↓
Almost nothing visibly happens
↓
Large background context/cache processing occurs
↓
Max allowance is consumed
↓
Paid Extra Usage may begin being consumed
↓
Normal usage UI does not identify which task caused it
I only discovered the likely relationship by manually investigating
Claude Desktop's local Cowork session files and `audit.jsonl`.
------------------------------------------------------------------------
### Claude Model
Opus
### Is this a regression?
I don't know
### Last Working Version
_No response_
### Claude Code Version
**N/A / Cowork via Claude Desktop**
### Platform
Anthropic API
### Operating System
macOS
### Terminal/Shell
Other
### Additional Information
## Financial impact
The behavior was discovered after my Max allowance was exhausted and two
paid Extra Usage purchases were consumed unexpectedly quickly:
``` text
2 × €23.80 = €47.60 total (including German VAT)
I have a separate support/billing investigation open with Anthropic.
I am not requesting a refund through this GitHub issue. I include
the financial impact because it demonstrates why background Scheduled
Task usage requires visibility and cost safeguards.
Possibly related issues
- #85912 --- *Hung Cowork scheduled task silently consumed full
Max 20x Fable allowance + \$1,031.92 in auto-recharges.* This is
closely related at the product/cost-safety level. I am not
claiming the same root cause; that reporter suspected a hung
persistent session, while I have not established an infinite loop.
- #52016 --- Cowork background/orphaned agents draining usage on
macOS. Potentially related because it involves unexpected background
Cowork activity, but again I am not claiming an identical root
cause.
- #83062 --- Relevant context involving unexpected paid usage and
reported unintended Claude Code/Cowork session behavior. I am
linking it only as related context, not as proof of a common cause.
Evidence available privately
I have preserved:
``` text
- local Cowork session metadata
- audit.jsonl files
- scheduledTaskId values
- local session IDs
- timestamps
- model identifiers
- input/output token fields
- cache_creation_input_tokens
- cache_read_input_tokens
- Claude Desktop logs
- usage-history data
- billing receipts
I am happy to provide sanitized relevant portions privately to Anthropic
Engineering.
I will not publish the complete session files because they contain local
filesystem information, task content, tool/plugin configuration and
potentially sensitive information.
### Why this matters
The central issue is not simply that Opus 5 can consume significant
usage.
The issue is that **Cowork Scheduled Tasks can apparently generate
enormous context/cache usage relative to the useful work performed while
the normal product UI gives the user almost no visibility or control
over that background consumption**.
Once Extra Usage is enabled, this becomes a direct financial-risk issue.
A Scheduled Task should be safe to schedule without requiring users to
reverse-engineer `audit.jsonl` afterward to understand where their paid
usage went.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗