Siri AI PCC planner: rate limiter reports count=320 over 86400 seconds while another PCC request still completes

I am investigating an intermittent Siri AI failure on an eligible iPhone running iOS 27.2 beta (24B5089g). I captured three sysdiagnoses covering a previously blocked state, a working state, and the transition from working requests into a repeatable failure. I also exported the corresponding Apple Intelligence Report.

The user-visible symptom is generic: Siri AI returns a variation of “Something’s gone wrong” for requests that require the agentic planner. Basic Siri functionality may remain available.

The transition capture contains the following sequence. Identifiers, request content, account information, and retry dates have been removed:

16:48:55.069  privatecloudcomputed  Ropes request finished successfully
16:49:08.770  privatecloudcomputed  Ropes request finished successfully
16:49:13.742  privatecloudcomputed  rate limit applied for rate with count=320, duration=86400.000000
16:49:13.790  privatecloudcomputed  PrivateCloudComputeError Code=32073
16:49:13.837  privatecloudcomputed  rate limit applied from cached denials
16:49:13.894  intelligenceflowd         deniedDueToUserDeviceRateLimit
16:49:15.439  privatecloudcomputed  Ropes request finished successfully

The Apple Intelligence Report aligns the planner failure with 16:49:13 and identifies the execution environment as PrivateCloudCompute. Another PCC request completed at 16:49:15, after the planner denial. This is consistent with the restriction being scoped more narrowly than complete PCC unavailability, although the successful request’s metadata is redacted in the unified log.

The log wording closely matches the rate limiter in Apple’s published PCC client source. In the 2026-05-15 source release, the client counts matching request records within a moving time window and denies a request when the count reaches a configured threshold. The same implementation stores cached denials and exposes an internal loggedCountSoFar field in TrustedCloudComputeRateLimit.

Relevant source locations:

• RateLimiter.swift
• RequestLog.swift
• DeniedRequestLog.swift
• TrustedCloudComputeRateLimit.swift

My current interpretation is limited to the following:

1. 320 appears to be the configured maximum for a matching request class, rather than a reading of the current count.
2. 86400 is consistent with a rolling 24-hour window. It does not necessarily mean that recovery occurs exactly 24 hours after the first visible denial.
3. One Siri interaction cannot be assumed to equal one rate-limit record. The published implementation records a request when it may be sent to ROPES, before the final inference result is known.
4. The evidence establishes rate limiting as the immediate cause of this planner failure. It does not establish how the rule is divided among device, iCloud account, feature identifier, workload type, or workload parameters.
5. Because Apple’s public source predates this beta build and does not include error 32073, source-level behavior should not be assumed to match this build in every detail.

I would appreciate clarification on these points:

• What is the intended scope of deniedDueToUserDeviceRateLimit in this Siri planner path: device, person/account, feature, workload, or a combination?
• Does count=320, duration=86400 describe a rolling window in current builds?
• Are attempts rejected from a cached denial excluded from the rolling request count? The published implementation appears to return the existing denial before the request-send accounting path, but I have not established that the current build behaves identically.
• Is there a supported diagnostic that reports the applicable rate-limit rule, loggedCountSoFar, and a non-redacted retry time to the device owner or through Feedback Assistant?
• Is it expected that another PCC workload can complete immediately after the Siri planner is denied?
• Should a user-visible generic Siri error distinguish this condition from network or service failures and offer a meaningful retry interval?

For comparison, another developer has reported a cumulative PCC wall that surfaced as either rateLimited or quotaLimitReached while the public quota state remained healthy: Developer Forums thread 843046. My capture differs by providing the client rule parameters and a Siri-specific deniedDueToUserDeviceRateLimit result.

I am retaining the original, unmodified sysdiagnoses and report export and can submit them through Feedback Assistant with precise timestamps. I am also running a low-frequency recovery observation and a same-account cross-device comparison. I will update this thread with recovery bounds and will correct the interpretation if later evidence does not support it.