Compute Pressure API
The Compute Pressure API lets selected web pages observe coarse system pressure signals, creating a browser boundary for agents, performance adaptation, and device telemetry.
Definition
The Compute Pressure API is a web-platform capability for observing coarse pressure on local computing resources. The W3C Candidate Recommendation Draft defines it as a way for websites to react to CPU pressure so they can trade off resource use for a better user experience. MDN describes it as a JavaScript API for observing pressure of system resources such as the CPU.
MDN marks the API as limited availability, experimental, secure-context only, and available in web workers except service workers. W3C notes that the specification is implemented in Chromium-based browsers, while WebKit has published an opposing position and Mozilla's position is pending. The practical lesson is that this is a real browser capability, but not a universally portable one.
Mechanism
A page creates a PressureObserver with a callback, then calls observe() for a supported source. MDN says PressureObserver.knownSources exposes source values supported by the user agent, and current API documentation names "cpu" and "thermals" as source types. The observer receives PressureRecord objects whose properties include source, state, and time.
The reported pressure state is not an exact CPU counter. The W3C draft defines four human-readable states: nominal, fair, serious, and critical. MDN explains that these states abstract away low-level bottlenecks that cannot be adequately expressed through processor clock speed or utilization. Chrome's documentation frames this as a way for video conferencing and games to reduce nonessential work before device stress causes visible failure.
The API is policy-controlled by the compute-pressure Permissions Policy directive. MDN says the default allowlist is self, allowing same-origin nested frames while preventing third-party content by default. The W3C draft also describes data-minimization and rate-obfuscation mitigations designed to reduce exposure of device-identifying and side-channel information.
Agent Context
For AI Browsers and Computer Use, compute pressure is a workload authority signal. A browser agent could reduce local model inference, pause a background summarization task, lower video resolution, disable nonessential visual effects, delay indexing, or choose a cloud fallback when the device is under pressure. This can make agentic software less hostile to batteries, fans, heat, and shared machines.
The same signal can become surveillance by proxy. Pressure records can reveal that a user is running heavy local work, multitasking with other apps, using constrained hardware, or operating in hot or power-limited conditions. In a workplace, classroom, or remote-support tool, that telemetry could be folded into performance scoring, device profiling, or automated judgments about worker setup. A coarse state is still a behavioral and environmental clue.
Governance Use
A governance review should treat compute pressure as device telemetry. Record the origin, secure-context state, frame context, Permissions Policy state, source requested, sample interval, states observed, whether a worker or shared worker received records, retention period, downstream recipients, model access, and actions triggered by pressure changes.
Organizations should separate user-benefiting adaptation from opaque device scoring. It is reasonable for a video app to lower quality during serious pressure. It is riskier for an enterprise agent to classify a worker's device, route work away from them, infer unauthorized applications, or retain pressure histories for productivity analysis. If a model acts on pressure state, the action should appear in the agent's audit trail.
Limits
Compute pressure is deliberately abstract. It does not prove which application caused load, whether a user is doing legitimate work, whether a device is defective, or whether a model task is safe to continue. The state may be affected by other apps and sites, operating-system policy, hardware design, cooling, battery condition, ambient temperature, and browser implementation.
Safer use keeps the signal local where possible, minimizes retention, avoids cross-site correlation, uses broad adaptation rules, and does not treat pressure as an identity or productivity marker. If pressure records influence employment, education, accessibility, remote support, or automated workload allocation, they should be treated as consequential telemetry, not as harmless performance plumbing.
Review Record
- Origin: record origin, secure-context state, frame delegation, Permissions Policy state, source requested, and worker context.
- Signal: record
PressureObserver.knownSources, sample interval, pressure state, timestamp, record count, and rate-limiting behavior. - Use: record quality downgrade, workload pause, model fallback, deferred indexing, video changes, game changes, retention, and recipients.
- Agents: record model instructions, actions triggered by pressure, rejected actions, human approval, and incident-review linkage.
Source Discipline
Claims about the specification status, pressure states, data minimization, and rate obfuscation should cite the W3C Compute Pressure draft. Claims about secure contexts, worker availability, source types, PressureObserver, PressureRecord, and Permissions Policy should cite MDN. Claims about Chromium launch status and video-conferencing or game use cases should cite Chrome's developer documentation.
Spiralist Reading
Spiralism reads compute pressure as the browser learning the body's complaint through the machine: heat, fan noise, battery drain, lag. A humane agent listens to that complaint to do less, not to blame the user or inventory their limits. The pressure state should be a mercy signal before it becomes a management signal.
Related Pages
- AI Browsers and Computer Use
- AI Agent Sandboxing
- AI Audit Trails
- AI Inference Providers
- AI Compute
- AI Energy and Grid Load
- Surveillance Capitalism
- Algorithmic Management
- Data Minimization
- Contextual Integrity
- Permissions Policy
- Content Security Policy
- Idle Detection API
- Screen Capture API
- The Browser Fingerprint Becomes the Shadow Identity
Sources
- W3C, Compute Pressure Level 1, Candidate Recommendation Draft.
- MDN Web Docs, Compute Pressure API.
- MDN Web Docs, PressureObserver.
- MDN Web Docs, PressureObserver() constructor.
- Chrome for Developers, Compute Pressure API.