When a page gets slow, who decides what survives?

A live show desk, a checkout on a mid-range phone, a control room dashboard: each one already has a private answer. Somebody hand-tuned what degrades first. An agent looking at the DOM cannot see that answer, so it either guesses or does nothing.

Every latency-sensitive page already has this cut list. Loadshed makes it explicit, agent-readable, and auditable.

Loadshed lets the page publish the answer. The page declares a click-latency ceiling, the element that must stay useful, and an ordered ladder of work it is willing to drop. It registers six WebMCP tools with document.modelContext.registerTool, so an agent can inspect the promise, negotiate the ceiling, protect a second element, apply or reverse one bounded cut, and read a receipt for everything that happened.

On the deployed Desk, a person drags crowd load to maximum and clicks once. The page measures a long frame of about 320 ms, drops the crowd layer from 480 items to 48, and leaves the live trace and mixer untouched. The agent set that contract, and the receipt names the frame signal, the caller, and the click that proved it. Turn the promise off and everything comes back.

The honest part: the runtime rejects agent-injected clicks as evidence, refuses cuts on protected or pinned work, and fails closed when the browser has no frame-hitch signal. The Sale page proves the same runtime protects a different task, Hold my size, without knowing the Desk's DOM.

No build, no backend, MIT licensed, 50 Node tests. Live site: https://mcs-eng.github.io/loadshed/ | Repository: https://github.com/mcs-eng/loadshed

Built With

Share this project:

Updates

Submission history