Anthropic’s October 14, 2026 release notes confirm that teams using Claude Platform on AWS can now schedule recurring Claude Managed Agents tasks. The change extends an existing capability to the AWS-integrated platform, giving operations teams another way to arrange regular reports and reviews without launching each run themselves.
This is an access expansion, not the first launch of Claude scheduling: Anthropic introduced the capability in June 2026. Managed Agents remains in beta. The October notice gives no exact rollout time or regional sequence.
First, check which Claude service you use
Claude Platform on AWS is operated by Anthropic, uses AWS authentication and bills through AWS Marketplace. It is separate from Amazon Bedrock and from a Claude chat subscription bought through Marketplace. An existing Bedrock integration is not the same setup.
An administrator must configure an execution role in the same AWS account and assign it to the agent. The configuring caller needs iam:PassRole, which the managed policies do not grant. Follow the AWS scheduling prerequisites for the role’s trust and session-creation permissions; a schedule alone is insufficient.
Check the data requirements too. Managed Agents keeps conversation history, sandbox state and outputs server-side and is not eligible for Zero Data Retention. That matters before putting internal reports into a recurring workflow.
Choose work that can tolerate the timing limits
Each scheduled firing starts a new session. A deployment combines the agent, its working environment and the opening instructions, with a schedule and timezone specified in the deployment configuration. For a recurring digest, explicitly define the reporting period and where to get current inputs; a new session does not by itself establish that the data is fresh.
Anthropic documents scheduling jitter—variation in launch time—of up to 15% of the interval, with a five-second floor and nine-minute cap on that allowance. This is launch timing, not a deadline for a finished report.
According to Anthropic’s AWS-specific guide, a session can work without user events for up to six hours. It then needs reauthentication through a user-role event before continuing. For longer unattended work, confirm the continuation procedure with the provider or divide the task into bounded stages; do not assume it will run indefinitely.
These limits suggest the following choices. This is a documentation-based decision framework, not a measured comparison of schedulers.
Your recurring task | Suggested approach |
|---|---|
A daily digest or weekly review with a flexible delivery window | Consider managed scheduling, with someone responsible for checking the result. |
A report needed at an exact time or after several upstream jobs finish | Keep the existing scheduler in control until deadline, dependency and recovery requirements are demonstrated. |
Work likely to need more than six hours without interaction | Plan supported continuation or smaller stages before relying on unattended runs. |
If session creation is rate-limited, the failure is recorded without another attempt until the next scheduled occurrence. Unrecoverable configuration errors can pause scheduling. Pausing stops future triggers, not existing sessions or manual runs; resuming does not replay missed triggers. See the failure and lifecycle rules.
A $20 run budget is not a $20 monthly limit
The published Managed Agents rates are model-token charges plus $0.08 per hour spent in running status, with web searches charged at $10 per 1,000 searches. Idle time is excluded from runtime charges. These are US-dollar list rates checked on October 15, not a fixed price for a completed report.
A deployment’s budget applies separately to each session. It is enforced using public list costs, which may differ from negotiated invoice charges. Once the threshold is reached, new model requests stop, but requests already in flight and their resulting tools can finish. The session pauses; the threshold is not an exact final-spend ceiling.
Hypothetical budget arithmetic: assume exactly 30 daily runs, each assigned $20. Their nominal thresholds total 30 × $20 = $600, before permitted overruns. Runs can spend less, while manual runs or extra attempts change the count. This is neither a forecast bill nor a $600 monthly cap. The $20 is an example setting, not a subscription price.
Separate runtime illustration: if those 30 runs each spend 30 minutes in running status, runtime alone is 30 × 0.5 × $0.08 = $1.20. Token usage, searches, external services, taxes and human review are excluded. This calculation uses the runtime rate; it does not estimate the total cost of the work.
Track the report, not just the launch
The deployment-run record contains a session identifier when creation succeeds, or an error when it fails. A created session is not evidence that a report finished or was correct. Keep the reporting period, launch status and accepted output together so a missing report cannot be mistaken for a report finding nothing.
For a first pilot, define:
Inputs and period: which sources to read, their cutoff time and the period the report should cover.
Delivery and recovery: where the result belongs, how late it may be and who investigates missing or incomplete work.
Acceptance and spending: who checks the output, the per-run budget and the expected number of monthly runs, including manual attempts.
Compare representative runs with the existing process before transferring responsibility. Record actual start times, checked outputs and charges. For investigating slow or failed sessions, see our guide to Claude’s tracing tools and data controls.
Methodology: This guide uses published product documentation, rechecked on October 15, 2026, and AI-assisted analysis. No agents were run or performance tests conducted. The calculations are hypothetical; the task-selection recommendations are analysis, not provider guarantees.