Thanks for the replies. I filed FB24515295 with the measurement driver, timestamped logs from both runs, and Feedback Assistant’s system diagnostics.
Ziqiao, you're right about the original rateLimited result, but to tighten up the recovery timing:
It followed cumulative usage, not request speed. The run sustained 39.7 generations/minute, and two bursts of 16 concurrent requests served 32/32 at 5.0 and 5.2 requests/second. The count also carried across a process restart and a 4.9-hour idle gap.
I didn’t actually observe it taking 20 hours to recover. Probes through +40 minutes all failed, and the next probe at +19.98 hours worked. So all I can really say is that recovery happened somewhere in the interval of (41 minutes, 19.98 hours].
After your reply, I deliberately ran the entitled app-tier driver to the wall again on the same macOS and Xcode builds. This time I got a pretty interesting contrast:
The 1,000-attempt run averaged 64.8 requests/minute.
The attempt right before the wall served in 840 ms.
The final attempt threw PrivateCloudComputeLanguageModel.Error.quotaLimitReached in 67 ms, not LanguageModelError.rateLimited.
Right before and after that error, quotaUsage still said belowLimit, not approaching, not reached, and resetDate = nil. Availability still said .available.
So this exact build can produce the expected quotaLimitReached error, but the earlier cumulative wall came through as rateLimited. The faster run also didn’t produce rateLimited, so request speed by itself doesn’t seem to explain the earlier result, though server conditions could’ve been different.
The sysdiagnose in FB24515295 was collected while this new quotaLimitReached block was active, so it captures the live quotaUsage and resetDate mismatch. I also attached the August 20 logs to the same Feedback report. Those cover the earlier rateLimited wall and recovery probes.
On the request shape... The hundreds of short, unique prompts are for diagnostics and development, not how I’m planning to ship quiz generation. I agree that the product should use a bounded, paced, on-demand, or on-device approach instead of firing off 500+ short PCC requests as one batch. I included the full driver so the framework team can see exactly what I sent.
If the team specifically needs a sysdiagnose from a wall that comes through as rateLimited, I can try again after the allowance refills. Since today’s same-build run returned quotaLimitReached instead, I can’t force which classification I’ll get. If there’s a logging profile or predicate I should enable first, let me know so the next run is as useful as possible.
Thanks!
