I subscribe to a lot of RSS feeds that are very sensitive to trends: The “popular” feeds from RiL services, the Hacker News front page, lobste.rs, and a few Google News topical feeds. I like the diversity of topics I get from it, but it’s also very susceptible to things coming through in waves. The past few days it has been the Mythos model, a spurt of Gemini features, Iran Iran Iran, reaction and counter-reaction, and counter-counter-reaction to a few high-profile articles about tech.

The triage UI lets me train the triage service on topics, but when I designed it I designed it less as a fine control and more as a rolling, broad collection of signals. I do have a feature that lets me block authors, but I don’t do it the way I think a lot of people would, to get rid of people I don’t agree with but rather because some reporters cover some things I never want to read about, and it’s a way to just whack out big tranches of material once I can see that the author covers a beat I don’t care about. Generally, though, the system is slowly and gently learning from what gets skipped, or very broadly named.

So when a big topical swell comes through, I haven’t had a way to deal with it. I don’t want to downscore the topic du jour because I don’t want to drive it from sight forever. I just want, after seeing the 10th article about it go by in the triage tool, to make it go away for a bit.

So this evening I built that feature in the form of a topic snooze:

I’ve got a Haiku agent doing the scoring on every article that passes into the system anyhow. It’s consulting my existing preferences and attention patterns and providing a little summary about why it’s scoring each article the way it does. So now I’m also using that inference pass to extract three or four likely topics from each article during scoring. The prompt is a pretty simple “figure out three things this could be about at a middling level of specificity.”

Those topics go into a table that records the topic and has columns for when it was first seen, when it was last seen, and how often it has been seen. While the topic is “live,” the system is just tallying and exposing the topic in the feedback UI for each article. If I triage an article, the UI shows me the inferred topics so I can choose to snooze them. If a topic gets snoozed, any articles it’s attached to that haven’t been selected for reading later get triaged out on the spot. For the duration of the topic’s “aliveness” – its rolling daily appearance average is above some threshold per day – articles about that topic get skipped without impacting the overall interest score for that topic. Once the topic slides below the “aliveness” threshold, articles matching it are allowed back into the queue.

I think it will be useful, and I made sure to include UI that lets me tune the params for defining snooze duration and the aliveness state for a topic. The nice thing about a tool like this is that it’s an opportunity to contemplate what harm would be done by not seeing an article I would have otherwise if I get something wrong with this, which is pretty much “none,” and that is a really good thing to remember.

It is also a variation on a theme that continues to emerge and evolve during this current period of vibecoding assorted tools and doing more to work inference into them than I was a year ago:

Even though the stakes are pretty low if the system gets it wrong, I always want my observation port and my knobs:

Inference is great in the spaces, doing things that I’d just consume a dependency to get (e.g. topic extraction) or understanding roughly – well enough – what my assorted likes and dislikes add up to for a given article. But I still want to be in the loop. Human in the loop doesn’t always have to mean “human hovering over the lever,” it can just mean “human nudging the flow this way and that.”

I want the system to gradually attain more and more autonomy as I stick to using it. I actually like it well enough now that I don’t even use RSS readers: I do triage in the mobile or desktop UI, and I use a RiL service to read what comes out the other side. Over the course of the day, about 8 percent of what comes through the system gets flagged for reading, and about 35 percent is auto-skipped before I have to triage it, either due to a deterministic rule (an author) or inference scoring.

When I pull the stats, I see that I’ve only overridden 2.3 percent of the inference system’s decisions. If I doubled the “kill with no review” threshold, I would end up not even seeing 40% of the total volume of content in feeds I’m subscribed to. I had Claude pull the numbers and did a quick sanity check with items I starred for later reading within that threshold, and it looks like I’d probably have 1.9% “regrettable autodeletes” if I just let the system become that much more aggressive.

I don’t have numbers on how much time I spend quickly reviewing kill proposals right now, but having 40% fewer things to even consider in exchange for maybe missing a good article or two a day seems like a decent tradeoff.