This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
I had 1,247 articles saved "for later." This week I le...
For further actions, you may consider blocking this person and/or reporting abuse
The most interesting part isn’t that you deleted 1,242 articles using AI. It’s that you built something that challenges our habit of collecting information we’ll probably never consume.
We often think having more saved content means we’re learning more, but sometimes it’s just digital clutter disguised as productivity. I also appreciate that you shared the 44% false-drop rate instead of hiding the uncomfortable part. That’s real engineering — showing what works, what doesn’t, and where things can improve.
Maybe the real productivity upgrade isn’t finding more things to read, but finally making peace with what we don’t need to read.
Brilliant experiment!
Thank you! That’s exactly what I was trying to explore with this experiment. At some point, saving more stops being useful and just becomes another backlog we feel responsible for.
And the 44% false-drop rate was important to include because the experiment definitely wasn’t perfect. For me, that failure is actually one of the more interesting results it shows where the idea needs work rather than pretending the model made every decision correctly.
Really appreciate you picking up on that.
"Permission to let go" is the sharpest line in the whole piece, and it is doing more work than the 1.66x lift. I have declared read-later bankruptcy by hand before, and the cost was never the reading time — it was the sunk-cost grief of all the intentions I had stacked up. The pile's real function is anxiety management: it keeps the option open forever. The model doesn't feel any of that, which is its only true advantage over human triage. My worry: does the keep-threshold dial just become the new hoarding knob — do you end up tuning UNPILE_KEEP_T instead of reading?
That last bit made me laugh because it's a very real possibility. You can end up optimizing the cleanup instead of actually reading anything. I didn't build Unpile to find the perfect threshold; I wanted to see what it felt like to let go of things I'd been holding onto for no good reason. The model doesn't carry that guilt, and maybe that's the useful part. But yes, if I keep tweaking UNPILE_KEEP to avoid every possible regret, I've just created another backlog, this time made of configuration decisions.
The confession hidden inside every cleanup system: the threshold becomes the new hoarding. I did the same with my read-later queue — declared bankruptcy on it last year after the saved count crossed a few thousand, and the relief lasted exactly until I started curating a new list "more carefully" this time.
Your line about the model not carrying guilt is the actual feature. It decides without mourning, which is the part humans can never automate.
Was there anything you flat-out refused to let it touch, or did the full purge apply to everything?
The “more carefully this time” part is painfully relatable. I think that's how we end up rebuilding the same backlog again.
And yes, the model not carrying guilt was a big part of the experiment. It could make decisions without the emotional attachment we have to things we've saved. That doesn't mean it always makes the right call, though. The 44% false-drop rate is a pretty clear reminder of that. The interesting question is how to get the relief of letting go without losing things you might genuinely need later.
"More carefully this time" is the whole cycle, isn't it? Every purge system I've built eventually becomes a museum of intentions. The guilt point is sharp — the model deletes without the little ceremony of 'but I might need this,' which is the actual hoarding mechanism. I wonder if the lighter feeling survives the first time you reach for something deleted and it's gone — that's the real test. Did you keep any safety net, or is the point that there is none?
Honestly, that's the part I'm curious about too. The relief is real, but I can't claim it survives the moment you need something that got deleted. The experiment was about seeing what happens when you let go of that attachment, not proving that every deletion was the right decision. The 44% false-drop rate makes that distinction pretty hard to ignore. A safety net like quarantine is worth considering, but it also raises the question of whether we're actually letting go or just moving the backlog somewhere else.
The 44% false-drop rate is the part I'd focus on. A saved RFC or a debugging write-up might look stale today but become useful months later when you're investigating a production issue. I'd put borderline items in a quarantine with a retention window instead of deleting them outright, and tune the threshold separately for evergreen technical docs and time-sensitive content. That way, the agent can still clear the backlog without treating "unlikely to read soon" as "never worth keeping."
That's a fair point. The 44% false-drop rate is exactly why I wouldn't treat this as a perfect cleanup system. Something I saved because it wasn't useful at the time could become valuable during a real debugging session months later. A quarantine with a retention window makes sense, especially for technical content. I went into this experiment wanting to reduce the backlog, but there's a difference between reducing clutter and losing something worth keeping. That's a trade-off I need to handle better.
Exactly. I'd also track what happens after retrieval, not just whether an article gets opened. An old postmortem about a PostgreSQL replication lag incident might sit unread for months, then become the most useful reference when a similar issue hits production. If the cleanup system only learns from recency and click history, it can end up removing the material with the highest value during an incident. Keeping those decisions reversible and measuring which items actually help during later searches would give you a much better signal than engagement alone.
this is the part that would actually change the model, not just the threshold. right now unpile only has the shallow signals, reopen count, recency, length, source, topic in-lane, and you're right that those are exactly the features that would silence that postgres replication postmortem, it looks dead until the night it's the only thing that matters. the problem is that "was useful during an incident" is a label that arrives months after the decision, so the model never gets to learn from it. engagement is easy to log and almost worthless here, an article you open for ten seconds and close scores higher than one you never opened but would've saved you a four-hour outage. what i'd need is a way to capture that late signal, something like a lightweight "this just saved me" mark when an old item actually gets used during a search, and feed that back as the real positive label instead of opens. that turns reversibility from a safety net into training data, the quarantine isn't just where mistakes wait, it's where the model learns what deferred value looks like. the honest catch is that signal is rare and slow, you might get a handful of those marks a year, so it's a long feedback loop to train on. how would you weight a signal that strong but that infrequent against the noisy high-volume engagement data, hand it a much higher weight, or keep the two label types completely separate?
I'd keep them as separate signals rather than just giving the rare one a huge weight. Imagine an incident where a team is debugging PostgreSQL replication lag. A postmortem saved eight months ago might explain how a long-running transaction and WAL replay delays interacted, even though nobody has opened it since. If that reference helps the team isolate the cause, that's a much stronger signal of technical value than a high click count, but it shouldn't have to compete with thousands of ordinary opens in the same loss function.
I'd track retrieval utility separately from engagement, then evaluate whether the system is actually surfacing useful material when similar incidents occur. One thing I'd be careful about, though: a "this saved me" mark is still selective feedback. People may forget to leave it, and the most useful document isn't always the one they end up finding. I'd use those marks as high-confidence positive labels, not as proof that everything without one is low-value. That gives the model a way to learn from delayed utility without letting a tiny, biased sample distort the whole ranking.
yeah, separate is the right call and you pushed me off the "just weight it higher" idea, which was lazy of me. the thing i kept missing is your last line, a missing "this saved me" mark is not evidence of low value, it's just absence, people forget and the doc that actually helped isn't always the one they consciously credit. so the mark can only ever be a positive label, never a negative one, the second i treat "no mark" as "drop it" i've rebuilt the exact bias that silenced the postgres postmortem in the first
place. so the shape is: engagement stays as the noisy day-to-day ranker, retrieval-utility lives in its own table as rare high-confidence positives, and absence stays unlabeled instead of being read as negative. that keeps the small biased sample from distorting everything, which is what you've been saying the whole thread. honestly this exchange gave me a cleaner spec than the article did. are you building something in this space yourself, or is this from running your own triage? you clearly have scars from it.
Wi-Fi off — that detail sells it more than any benchmark. An overnight job that has to survive a router reboot is the only kind that ever actually runs, and the deterministic fallback is what makes it survive. The number that earns trust here is the 44%: most triage demos stop at precision and lift, and the wrongly-dropped row is the only one that tells someone what they're actually signing up for. All the threshold dial does is move the guilt somewhere else — every setting is a choice about which morning loses what. 0.60 precision against a 0.36 base rate is real, modest, and honestly the smaller half of the value; the bigger half is deleting without guilt, which is the one thing no sorting algorithm can do for a person.
the wi-fi-off line being the part that sells it is the read i didn't expect but you're right, that's the whole reason the fallback exists. an overnight job that dies the moment the router hiccups or ollama isn't reachable never actually runs, so the deterministic template isn't a nice-to-have, it's the thing that lets the job finish at all. a benchmark you can only hit online isn't an overnight tool, it's a demo. and "every setting is a choice about which morning loses what" is a sharper way to say it than i managed in the whole post, the threshold doesn't remove the cost, it just picks whose saves pay it. the last line is the one i keep circling back to, deleting without guilt is the only part a sorting algorithm genuinely can't do for you, everything else is just ranking. thanks for reading it this closely.
Local-first triage is more convincing when deletion remains reversible and inspectable. I would retain a compact decision receipt for each removal—ranking features, model version, and a restore window—so the system can be tuned from mistakes without turning the archive into another cloud service.
you just described the direction unpile is already leaning, which is reassuring to read. it never hard-deletes, it silences, so the item is archived not gone, and every decision already carries its reason so you can inspect what got dropped. where you're ahead of me is the "decision receipt" being a real structured artifact, ranking features plus model version plus a restore window. right now my reason is more of a human-readable line than a tunable record, so i can read why something was dropped but i can't easily replay the exact feature weights and model version that made the call. that version field is the part i underrated, because the moment i retrain, old decisions stop being comparable unless i stamped which model made them. and keeping all of it local is the whole point, the second it becomes a cloud service it's just another pile with a login. curious how you'd store the receipt, inline next to each item, or a separate append-only log you can diff across model versions?
I would keep the current state with the item for fast restore, and a separate append-only decision table keyed by item ID for the history. Each event could include the model and feature schema versions, inputs or their snapshot reference, decision, and timestamp. Write the state and event in one local transaction so they cannot drift; retention and export controls matter because those inputs can themselves be sensitive.
yeah, that split is the right shape and cleaner than what i had in my head. current state next to the item so a restore is cheap, history in a separate append-only table keyed by item id so you can diff across model versions without bloating the hot path. the one-transaction point is the part i'd have gotten wrong, if the state write and the event write can drift you end up with an item that says "kept" and a log that says "dropped" and now neither is trustworthy. stamping the model and feature-schema version on every event is what makes the history actually replayable after a retrain, which is the thing i was missing. and the retention/export line matters more than it looks, those feature snapshots can hold what i was reading and when, so an append-only log of my reading intent is its own sensitive thing, keeping it local and prunable isn't optional. this is basically the receipt spec for the next version, thanks for spelling it out.
Respect for putting the 44% wrongly-dropped number right next to the precision. Most people would only show the 0.60. Did you try a baseline with just the reopen count? I'd guess "I reopened this tab twice" carries a lot of the signal on its own, and it'd be interesting to see how much TabPFN adds on top.
good question and it's the one i should've put in the article. i didn't run a clean reopen-count-only baseline, which in hindsight is the obvious ablation. my gut agrees with you, "reopened twice" is probably carrying a big share of the signal on its own, reopens are about the strongest intent signal in the whole feature set. what i think tabpfn is adding on top is the interaction between reopens and the softer features, source, length, how stale the save is, topic being in your lane, a single reopen on a short in-lane how-to means something very different from a single reopen on a long off-topic piece saved eight months ago, and a plain reopen threshold can't see that. but "i think" isn't "i measured," so that's a real gap. the clean test is reopen-count logistic regression vs the full tabpfn feature set on the same held-out slice and just read the lift difference. did your file-sorter end up leaning on one dominant feature like that, or was the signal spread out more evenly?
the 44% wrongly-dropped figure next to the 0.60 precision is the honest move in this whole post, and it's the one i'd act on before pointing it at a real pile: at that setting you're silently throwing away nearly half of what you'd actually read, so UNPILE_KEEP_T needs to be tuned per person, not shipped at a default. the "did you ever read it" label is the right training signal too, because it captures the gap between saving and reading that no clickstream does. one thing i'd add from running a similar triage on my own reading backlog: the digest quality is where the tool wins or loses, and a two-line Gemma note that just restates the title reads as noise — the keep/skim/drop reasons are the part worth surfacing in the morning, not the summaries.
the digest point is the one that actually lands, and i think you're right. a two-line gemma note that just restates the title is noise, i've seen it do exactly that on short posts where there's nothing to summarize so it pads. the keep/skim/drop reason is the real signal because it's a decision, not a recap, "drop, off your lane and eight months stale" tells me more in the morning than any summary of the article itself. i've been treating the digest as the headline feature when the reason line is the thing people would actually read. on the threshold you're also right that a shipped default is wrong, 44% dropped at one global setting means i'm punishing people whose reading taste doesn't match mine, it has to be tuned per person or better, learned per person from their own "did you ever read it" history instead of a dial they set once and forget. did your own backlog triage end up needing a per-person threshold too, or did you find one setting that held up across different kinds of saves?
Fantastic article and very useful software. My 2nd brain repo had a ton of early article links I would try to read but it got too much. I cleaned up those stores and finally settled on some human triggered scripts backed by LLM that finds new articles and extracts the core ideas and saves under topics. If it’s a +1, it updates a score. I focus on various topics like AI adoptions challenges, agentic and so on. As I pick new projects, I refer to those learnings to apply to my PRDs, design and so on. I try to run cleanup and compact the learnings. Compaction is a harder part as that’s where I need to invest more as LLM does not understand. I have a topic, interest list Md file that guides but it’s still not perfect.
this is a really good setup, honestly more disciplined than what i did. the compaction part you mentioned is the exact wall i kept hitting too. the llm is fine at pulling core ideas out of a single article but the moment you ask it to merge ten notes on "agentic challenges" into one compacted learning, it either drops the specific detail that made the note worth keeping or it blurs everything into generic mush. i didn't solve that in unpile, i side-stepped it, the model only decides keep/skim/drop and writes a short digest, it never tries to compress the actual knowledge. the scoring idea where a +1 bumps a topic is clever though, that's a real signal and it's yours, not some average. one thing i'm curious about, when you compact, are you compacting at the topic level or per idea? i found topic-level compaction is where the detail dies, because two ideas under
"ai adoption" can be saying opposite things and the llm averages them. keeping compaction per-idea and only grouping at read time felt safer when i thought about it, but i never built it. how are you handling that today?
Deleting 1,242 articles on purpose takes guts. How did you protect yourself from the model deleting something you wanted? I used preview + undo for the same fear in my file-sorting entry.
honest answer, for this experiment i didn't have a hard undo and that's a fair hit. unpile's real design keeps it safer, it doesn't hard-delete, it silences, so the item is archived not gone, and every decision ships with the reason it was made so you can scan what got dropped. the 44% wrongly-dropped number is exactly why a preview + undo like yours is the right call, i'd rather move the cost to a rare reach-back than to a permanent loss. going to add a proper quarantine window in the next version. nice approach on the file-sorting entry.
This is intresting great work
Thank you so much
Very informative essay thank you for sharing!
Thank You So Much!
A deletion workflow earns trust when it has a clear recovery story. A staged queue, short grace period, and a digest of why each item was selected let the model be aggressive without making one bad ranking permanent. Local-first makes that much easier to design well.