Wake up to answers with Sift

The problem

I find a lot of good links on my phone, mostly from X or Instagram - a new tool, a GitHub repo, a smart workflow. I used to send each one to myself on WhatsApp to read later.

Then I never read them.

Why it was a problem for me

The list failed me in two ways. First, I forgot it existed. When I sat down at my laptop, the links were out of sight, out of mind. Second, when I did remember, I had no time. Each link needs work first. Is the tool real? Is it still maintained? Will it run on my hardware? Does it fit anything I’m working on? So the links just sat there and went stale.

The solution

So I built Sift. Now I paste the link into a “Sift” topic in my Telegram group (about two seconds). The bot replies “Saved to Sift.” and that’s it.

At 3 AM a job picks up the day’s links. For each one it reads the actual page, runs a few web searches, and asks an AI model (Claude) a fixed set of questions: is it real, who made it, do I already have something like it, and is it worth my time this week?

At 7:15 AM a short report shows up in Telegram: how many links came in, and the one to three worth acting on. It links to the triage note in Obsidian (my notes app), as does my daily note.

Now I start the day from finished research instead of a cold list.

You can build your own Sift in an evening, plus a quick look the next morning to see that the night run worked. First comes what you need, then six steps. Each step ends with a check, so you know it worked before you go on, and with the snag I’d expect most. If you’d rather not type it all, the prompt at the bottom of this page walks a coding agent through the same six steps and the same checks.

What you need

• A computer that is awake at 3 AM. See the next part. This is the one people miss.
• Claude Code, signed in with a Claude plan or set up with an API key. The night job uses it to research and judge each link.
• Telegram on your phone.
• Bun, a program that runs TypeScript. Claude Code can install it for you. I used TypeScript, but any language works.
• A folder for notes. Any folder of Markdown files works. I use Obsidian, but you don’t need it.
• Optional: a free GitHub account, for a token that lets you check more repos each night.

I built it on a Mac. Linux works the same way, with cron or systemd. On Windows you’d use WSL or Task Scheduler, which I haven’t tested. I run Sift on Daniel Miessler’s PAI and use its scheduler, but you don’t need PAI. Your computer’s own scheduler does the same job.

Your computer has to be awake at night

The night job runs at 3 AM. If your computer is asleep then, nothing runs, and in the morning there’s no report and no error to tell you why. You have three options:

• Use a computer that stays on, like a desktop or a small always-on box. That’s what I do.
• On a laptop, keep it plugged in and set it not to sleep while it’s plugged in. Or schedule a wake a few minutes before the job. On a Mac that’s sudo pmset repeat wakeorpoweron MTWRFSU 02:55:00.
• On a Mac, use launchd instead of cron. If the Mac was asleep at 3 AM, launchd runs the job when it wakes up. Cron just skips it.

What it costs

My night job calls Claude Code on my Claude plan, so there’s no separate bill, but it does use some of the plan’s usage. That’s why each night has a cap on links. If you use an API key, you pay for each call instead. Either way, start with a cap of about 10 links a night, and look at your usage page the first morning before you raise it. The other tools here are free at this size.

How a script talks to Claude

You probably use Claude in a chat window. A script can’t type into a chat, so the night job runs Claude Code in print mode: claude -p "<your prompt>". Print mode takes the prompt, prints the answer, and exits, with no one at the keyboard. It uses the login Claude Code already has, so sign in once in a terminal before you schedule anything.

The night job reads pages that strangers wrote, and a page can hold text that tries to give the AI orders. So I give the research call one tool, web search, and the analysis call no tools at all. The worst a bad page can do then is spoil one note. Don’t run the night job with a flag that skips Claude Code’s permission checks.

Day side and night side

Sift has two halves. The day side is a bot that saves each link you send it in about a second, and does no other work. The night side is two scheduled jobs: one at 3 AM does the slow work on every saved link, and one at 7:15 AM sends you the report. A queue file sits between them. This split keeps saving instant, and it puts every AI call in one capped batch, so the cost is easy to predict. Steps 1 and 2 build the day side. Steps 3 to 6 build the night side.

Step 1. Make a capture inbox in Telegram

A bot is a Telegram account that a program controls instead of a person. In Telegram, message BotFather, send /newbot, and pick a name. BotFather replies with a token. The token is the bot’s password: anyone who has it controls your bot.

Before you save the token anywhere, make a .gitignore file that lists .env. Then put the token in .env, the private file that holds this project’s secrets. git keeps every version of every file. If you commit the token once, it stays in the history even after you delete it, and the only fix is to revoke it in BotFather.

Then pick where you’ll paste links:

• The simple way: a private chat with your bot. If Sift is the bot’s only job, every message in that chat is a capture.
• What I do: a “Sift” topic in a Telegram group with topics turned on. (A topic is a separate thread inside one group.) My bot does other jobs too, so the topic keeps Sift links apart. Make the bot a group admin with the “Manage topics” right. An admin bot sees every message, and the Telegram Bot API lets it make the topic with createForumTopic. If you don’t want it to be an admin, turn privacy mode off in BotFather (/setprivacy), then remove the bot from the group and add it back. The change doesn’t reach a group the bot is already in.

The bot is one long-running program that uses long polling: it keeps asking Telegram “anything new?” and waits for the answer, so your computer doesn’t need a public web address. You don’t have to look up IDs by hand. Send the bot one message, and Telegram’s getUpdates reply shows your chat ID, your topic ID (message_thread_id) and your own user ID.

Make the bot accept messages only from your own user ID. Anyone can find a bot by its username, and without this check a stranger could fill your queue and spend your Claude usage. In a group, check the topic first, before any other message handler, so a pasted URL can’t be read as a command.

Keep capture cheap. The bot saves the link and replies, with no AI call and no fetch, so saving is instant. I also kept a link: <url> prefix as a fallback for other chats. It still only works for my user ID.

Check: paste a link, and within a few seconds the bot replies “Saved to Sift.”

Common snag: no reply. First make sure the bot program is still running in your terminal. (Step 3 keeps it running after you close the terminal.) In a group, make sure the bot is an admin.

Step 2. Write each link to an append-only queue

The queue is a text file with one line per saved link, written in JSON, a plain-text format that programs read and write. Append-only means the bot only adds lines at the end and doesn’t change old ones. Adding one line is safe even while the night job is reading the file.

{"id":"3f9c2a7b1e04d8a6","url":"https://example.com/new-tool","note":"for the newsletter","source":"telegram","capturedAt":"2026-10-21T05:12:44.000Z","captureDate":"2026-10-20"}

Make the id from what came in: a hash (a short fingerprint) of the URL, the message ID and the capture time. Don’t make it from anything the fetch or the model returns, or a page edit turns into a “new” link. The night job keeps a separate list of processed IDs, and it adds an ID only after that link’s note section is written. So if a run stops halfway, the next run finishes the rest and skips the links that are done. If you save the same URL twice you get two items, and that’s on purpose. The repeat log in Step 6 tells you about it.

Store captureDate in your own time zone. In the example, 05:12 UTC is still the evening of the 20th in Pacific time. That date decides which daily note the link goes into later.

Check: save two links. The queue file has two lines with two different IDs, and captureDate is today’s date where you are.

Common snag: the date is tomorrow’s. That means the code used UTC, so ask for your time zone instead.

Step 3. Schedule the jobs and keep the bot running

A scheduler is a clock on your computer that runs a command at set times. You need two jobs. drain runs at 3 AM and does the slow work, and report runs at 7:15 AM and sends the headline. At this point both are empty shells that start and exit. Steps 4 to 6 fill them in.

In cron, each line is a time and then a command. The five time fields are minute, hour, day of month, month, and day of week, and * means “every”. So 0 3 * * * means 3:00 AM every day.

# minute hour day month weekday  command
0  3 * * *  cd /path/to/sift && /full/path/to/bun run sift.ts drain  >> sift.log 2>&1
15 7 * * *  cd /path/to/sift && /full/path/to/bun run sift.ts report >> sift.log 2>&1

A scheduled job starts with an almost empty setup. It doesn’t load your shell settings, so it can’t find tools by name, and it starts in your home folder. So each line moves into the project folder first, calls Bun by its full path (which bun prints it), and adds its output to a log file. On a Mac, ask your coding agent for launchd jobs instead of cron lines. They do the same thing, and they catch up after sleep.

Use the same scheduler to keep the bot running. On a Mac that’s a launchd job with KeepAlive, and on Linux it’s a systemd service with Restart=always. Either one starts the bot when you log in and restarts it if it crashes.

Every run exits with code 0, the signal for “finished normally”, even when the queue is empty or a link won’t load. Problems go in the log and the note. Some schedulers pause a job that keeps failing, and one bad link shouldn’t switch off your whole night.

Check: run both jobs by hand with an empty queue. Type echo $? right after each one, and it prints 0. Then set a test run two minutes from now, wait, and read the log. Last, close the terminal and paste a link. The bot still replies.

Common snag: the job works by hand but not on schedule. If the log says “command not found”, use the full path. If the log is empty, the computer was asleep or the time line has a typo.

Step 4. Fetch the real content, by medium

Pick the fetch method from the URL. For a first build, web pages, GitHub repos and papers are enough. Add Instagram later.

• Web page: get readable text from a reader service like Jina Reader. You put r.jina.ai/ in front of the URL and get the page back as text, with no key needed for a few pages a night. Then render the page in a headless browser, which is a browser with no window that a program drives. I use Lightpanda, and your coding agent can install it. Prefer the rendered text. Only use the reader text when the render comes back empty. Gotcha 1 below is why.
• GitHub repo: call the GitHub REST API, an address a program calls to get data. Stars, the last push date and the archived flag tell you if the project is alive. It works without a token for a few repos a night, and a token raises the limit.
• arXiv paper: fetch the arXiv abstract page, not the PDF.
• Instagram (optional): read the caption and author only, with yt-dlp for reels and gallery-dl for image posts. Both need a logged-in session cookie. A session cookie is a login: whoever has it can act as you, so treat it like a password.

From long text, keep the densest window: the stretch of about 4,000 characters with the most real sentences. The top of a page is usually menus, and a smaller window keeps each model call small.

Check: fetch one web page, one repo and one paper. The first lines of each are real content, with no cookie banner and no menu.

Common snag: the first lines are a cookie banner or a menu. That means the render failed or its text wasn’t used. Check that the headless browser is installed and that the code prefers its text.

Step 5. Research, then ask the model fixed questions

Before the analysis, run two or three web searches about the tool and who made it. I use the web search tool in Claude Code, through print mode with only that tool allowed. Keep only findings whose source URL was in the real search results. Number them, so the model can cite them as [1] and [2].

Then give the model the page text, the research, your note, your lanes, a short list of what you already run, your computers, and today’s date. Ask for strict JSON, which means only the JSON object with no other text, so the program can read it:

{
  "type": "repo",
  "lane": "<one of your lanes>",
  "isNoise": false,
  "title": "Example Tool",
  "summary": "Example Tool converts web pages to clean text. It runs as a local command.",
  "real": "The repository has working code and recent releases [1].",
  "maintained": "The last push was in October 2026. The repository is not archived.",
  "whoBehind": "A small open-source team [2].",
  "duplicates": "My current page fetcher does the same job.",
  "fit": "Skip it. It does not add a feature I need.",
  "actWorthy": false,
  "nextStep": "skip",
  "smokeTestPlan": ""
}

A lane is the area of your life a link could serve. Mine are my own systems, my day job, and a possible business, but pick your own. “Worth acting on” is your rule too. Write down what makes a link worth your time this week, and put it in the prompt.

A smoke test is two to four install-and-run commands that show a tool works. Write a smoke-test plan only for repos and tools that are worth it, and don’t run it at night. Running code from the internet stays a manual step that I approve.

Check: run your three test links. Each answer parses as JSON. Each [1] or [2] matches a URL from the search results, so open one and look. The hardware answer matches what the real page says.

Common snag: the JSON doesn’t parse, because the model wrapped it in a code fence or added a sentence. Strip the fence and retry once. If it still fails, mark that link as failed in the note and go on to the next one.

Step 6. Write the triage note and send the headline

Each night, write one dated note in your notes folder with a section for each link. The morning job then sends a short Telegram message: how many links the night job did, how many failed, the one to three worth acting on, and a link to the note. On your phone, the link opens only if your notes app syncs there. The message is still useful without it.

If you keep daily notes, add the note link to the daily note for the capture date. If that daily note doesn’t exist yet, save the link and add it on the next report run. Don’t write it into a different day.

Keep a log of every link Sift has seen. If you save the same thing twice, the report says so.

Optional: each item in my note has a “Give next steps” link. It opens Telegram with a message already typed. I add what I want and send it to my assistant, which picks it up from there.

Check: run drain and then report by hand with your three test links. You get one Telegram message, the note opens, and the right daily note links to it. Run drain again, and it finds no new work.

Common snag: the log says the job ran, but no note appears. On a Mac, a scheduled job can be blocked from Documents, Desktop and iCloud Drive. Move the notes folder, or give the scheduled program access in System Settings > Privacy & Security.

The first real night

The next morning, check three things. The report arrived at 7:15. The log shows a 3 AM run with no errors. And your Claude usage page, or your API bill, shows what one night used. If the report didn’t come, the log tells you which half failed. No log line at 3 AM means the computer was asleep.

Settings worth copying

• Plain words in the output. My prompt tells the model to write every field in ASD-STE100 Simplified Technical English. That means short sentences, one idea each, active voice, and no jargon. The notes are fast to skim at 7 AM.
• A hardware check. The prompt lists my computers. The model has to pull out each hard requirement (chip, GPU, RAM, OS) and say no when my hardware fails one.
• A repeat check. I keep a log of every link Sift has seen. If I save the same thing twice, the report says so.
• An optional skip rule. I send links about health past the normal analysis, and a stronger model reviews them later. You can do the same for any topic you want handled with more care.

Gotchas I hit

1. The reader dump included a cookie wall. My first fetch only used the reader service. On a lot of pages it returned everything - the mega-menu, the footer, and the whole EU cookie and terms banner. My “find the densest text” step then picked the legal text (legal text is dense, real sentences), and my thin-content check passed it. So the model judged the tool on its terms of service. One verdict said a tool wouldn’t run on my Macs, when the real page said it did. The fix: for every page that isn’t a repo, always render it headless and trust the rendered text first.
2. Make the dedup ID from the input. If the ID depends on the fetched body or the model’s answer, a page edit or a new model run makes a “new” item. Then you research the same link twice. Hash only what came in.
3. The model’s knowledge is out of date. Early on, the model called a real, newly released AI model “fake,” because it had never heard of it. Now each run gets the current date, a rule that “I don’t know it” is not evidence, and the web research pass. Only real sources can back a claim that something doesn’t exist.
4. “Thin” is not the same as “short.” A 200-character Instagram caption is the full content. Flag a fetch as thin only when it captured no real text. Thin items get a “retry in a browser” note. They never get marked as noise.
5. Login walls need a saved session. Instagram shows nothing to a logged-out fetch. I export the session cookie to a private file (owner-only permissions, never committed to git). The night job reads that file, so it doesn’t need an open browser. The cookie lasts about six months and can’t be refreshed. A weekly check warns me only when it’s close to expiring.
6. Night jobs have a short PATH. A scheduled job doesn’t load your shell setup. Command-line tools that work fine in your terminal can fail silently at 3 AM. Call them by their full path.
7. Don’t grind long video at night. Short clips are fine. A six-hour conference video would run for hours. Gate on length, and only transcribe long video when you ask for it.
8. Exit clean. The scheduler in PAI pauses a job after it fails three times in a row, and other schedulers have their own version of this. So a night with an empty queue, or a link that won’t load, still has to exit with code 0. Report problems in the log and the note, not in the exit code.

• Daniel Miessler’s PAI: the personal AI system Sift runs on, including its scheduler.
• Claude by Anthropic, through Claude Code: the analysis and the web research.
• Telegram Bot API: capture and the morning report.
• Lightpanda: headless page rendering.
• Jina Reader: first-pass readable text.
• GitHub REST API: repo health signals.
• yt-dlp and gallery-dl: Instagram captions.
• arXiv: paper abstracts.
• Obsidian: the triage notes and daily notes.
• Bun: the TypeScript runtime.
• Music in the tutorial video: ‘Greenpoint Avenue’ by auv on Uppbeat.
• ASD-STE100 Simplified Technical English: the writing rules for every note.

Paste this into Claude Code (or another coding agent) and it will build Sift with you, asking for your own keys as it goes. It follows the same six steps and checks as above.