Should feeds have a user-controlled attention budget?

I’ve become wary of infinite feeds, especially the reflex of opening an app for one thing and resurfacing much later. I’m wondering about a user-controlled “attention budget”: recommendations would be collected locally and shown in scheduled digest windows, rather than refreshing continuously. Messages, mentions, or chosen accounts could still arrive immediately.

This seems technically plausible without trusting a platform’s wellness dashboard. A browser extension could hide the feed container or block loading outside the window; Android or Apple focus controls could add device-level friction; open APIs such as Mastodon’s or Bluesky’s could let clients fetch and batch timelines where available. The catch is that extensions need permissions, can be bypassed, and interfaces change. Delayed feeds might also make communities feel slow or miss live moments. I don’t see this as a cure, just a different default. Would you use it, and what safeguards or failure modes worry you most?

I’d use it, but I’d be careful about claiming it reduces compulsive checking. The plausible mechanism is removing the cue-response loop; the outcome still needs testing. A useful evaluation would compare checking frequency and missed messages, not just ask whether people feel more in control afterward.

The enforcement point matters. If the extension merely hides cards after the page has already fetched them, it is mostly theater. Blocking feed requests is stronger, but host permissions and site breakage become the price. An API-based client is cleaner, though it immediately runs into platform coverage.

“Client-side” is not the same as trust-free. An extension can read page content and browsing activity depending on its permissions, so schedules and logs should stay local and the permission surface should be tiny. I’d also want an obvious emergency bypass, with a cooldown rather than a secret back door.

My concern is social latency. The value of a small community can be the five-minute exchange, not the polished daily bundle. I’d want separate budgets: recommendations batched, direct replies immediate, and maybe a short-lived live channel for events. Otherwise users may simply keep a second app open.

This is a good fit for a local-first reader: keep the schedule, cursor state, and selected-account rules on the device, then sync only if the user asks. ActivityPub and documented timeline APIs make parts of that feasible, but there is no universal client for every recommendation feed.

I’m less optimistic about the “budget” metaphor. People may spend the whole digest window bingeing what was accumulated, then blame themselves when the product design remains manipulative. Batching changes the rhythm, but ranking, autoplay, and notification pressure can still do the damage.

I’d install it tomorrow if it worked across browsers and didn’t need an account. The likely failure mode is less philosophy than maintenance: one interface redesign, one new device, and the old habit is back. Still, a leaky fence is better than no fence if it is honest about being leaky.