Just noting that the specification for this API is ready for review.

We haven't finished discussing this, but one thing we're skeptical about is the idea of leaving the buckets implementation-defined. Can you give us a rough algorithm that might be interoperable?

@nickie, just wondering if you've fed this to Gemini for a review?... it confirmed a lot of concerns for me personally that I had with the proposal.

Here's a prompt. Hope that helps in the meantime while we do human reviews.

You are a critical reviewer of web platform proposals. Your job is to find real problems, not to validate the proposal. Do not assume good design because the proposal exists. Apply the following tests rigorously.

Proposal: https://github.com/WICG/cpu-performance/ Fetch and read the full explainer and spec before answering anything.

Test 1: Use-case coverage by existing APIs

For each use case listed in the proposal, determine whether an existing W3C or WHATWG API already provides a more direct signal. Specifically:

• For video/media use cases: evaluate MediaCapabilities.decodingInfo() and VideoDecoder.isConfigSupported() (WebCodecs). Does either API answer the question the proposal claims requires CPU tier? Quote the relevant spec text for each.
• For ML/AI use cases: evaluate the WebNN API, specifically opSupportLimits() and the UA compute-unit selection model. Does WebNN already address on-device vs. server-side inference decisions without requiring CPU tier? Quote the spec.
• For each remaining use case: is there an existing API that provides a more accurate or more targeted signal than a 4-tier CPU classification?

Conclude: which use cases, if any, are genuinely unmet by existing APIs?

Test 2: The reproducibility claim vs. OS reality

The spec requires the same device to always return the same tier regardless of current system state ("reproducibility: independent of current load").

Evaluate this claim against:

• Thermal throttling behaviour on mobile SoCs (ARM big.LITTLE, Apple M-series, Qualcomm Snapdragon)
• OS power profiles (Windows Balanced/Performance/Power Saver, Android Doze, iOS Low Power Mode)
• Battery state effects on CPU boost duration
• Background process load (OS indexing, antivirus, system updates)

Is "reproducibility independent of current load" achievable in practice? If the tier reflects nominal device capability but not current operating conditions, what is the practical accuracy of the tier for the real-time adaptive use cases the spec describes?

Test 3: Privacy and fingerprinting surface

The spec says it was designed with privacy in mind. Evaluate:

• What is the information gain from navigator.cpuPerformance when combined with navigator.hardwareConcurrency, navigator.deviceMemory, and WebGL renderer strings? Does the 4-tier bucketing meaningfully reduce fingerprint entropy compared to those signals combined?
• The spec requires SecureContext but defines no Permissions Policy feature. What does this mean for cross-origin iframes and third-party scripts?
• The tier is stable by design ("no reclassification"). How does a permanent, stable signal interact with cross-session fingerprinting?
• The spec explicitly lists "Select ads that are better suited for the user device" as a use case. Tier 1 devices correlate with lower-income users. Is there a consent mechanism for this use? Should there be?

Test 4: Abstraction level

Chrome internally classifies devices into performance tiers for rendering heuristics (compositor thread budgets, animation scheduling, etc.). Safari does the same.

• If UA-internal classification already exists, what is the marginal value of exposing it to web content as a static property vs. as a dynamic media query (e.g. @media (performance-tier: low)) that the UA updates based on current system state?
• prefers-reduced-motion and prefers-color-scheme are OS-mediated signals surfaced as media queries. What are the tradeoffs between that model and the navigator.cpuPerformance model for this use case?

Output format

For each test:

1. State your verdict: passes / fails / partially passes
2. Give the specific evidence (quoted spec text, API behavior, OS behavior) that supports the verdict
3. If it fails, state what would need to change for it to pass

End with an overall assessment: does the proposal justify shipping as specified, or does it need rework? If rework, what is the minimum viable change set?

Do not hedge. If the evidence points to a problem, state the problem clearly.

Can you share the output of your Gemini prompt? I'm surprised the prompt reduces things a "pass/fail" verdict, when all of the questions in each test are more discussion oriented, and not binary.