The Show HN (7 points, 3 comments, posted 13:23 UTC Tuesday by rnoro_) opens with the failure everyone with a GPU box has had: "Every time I ran a training loop for a few days via Jupyter Notebook and ran into issues (network disconnected, my laptop suddenly died, etc.), I suffered from losing my ipykernel and cell outputs." The README's framing is the useful part, because it refuses to blame any one tool and names the shared cause instead. JupyterLab reconnects but everything printed while you were away is gone, since "iopub output is streamed over the WebSocket and never persisted server-side, so there is nothing to replay." VSCode Jupyter ties the kernel to the extension-host process, so closing the window kills the kernel. tmux plus jupyter console survives the disconnect but loses rich output and cannot be opened from a second client. "The root cause is the same in all three: the source of truth for your session lives on the client, or in a channel that doesn't outlive a disconnect. Tithon moves it to the host." The implementation is specific enough to argue with. The kernel runs detached under setsid so it is not a child of the daemon, and re-attaches through a persisted connection file when the daemon crashes, restarts, or gets upgraded. Every iopub and shell message is journaled verbatim to append-only SQLite in WAL mode, alongside a per-execution folded snapshot of current display state, so a reconnect is a snapshot plus an ordered gapless delta rather than a replay of everything. Clients attach with the last sequence number they saw. Rich outputs are stored as files referenced by hash and never base64-embedded, ipywidgets traffic is folded into a widget-state+json snapshot so a tqdm bar comes back at its real value, per-subscriber buffers are capped so one slow client cannot grow daemon memory, and the daemon binds a 0600 unix domain socket with no TCP at all. The README demonstrates the claim rather than asserting it: run some code, pkill -9 -f 'tithon daemon', restart it, and tithon attach --since 0 --once brings the earlier output back with kernel state intact.

The VSCode side is where a design decision gets made that will decide whether you want this. The extension opens a percent-format .py — a plain script with # %% markers — as a notebook backed by the daemon, with the same cells and the same rich output as an .ipynb, and outputs are matched to cells by content hash so they survive edits and reopens, with an edited cell's output flagged stale. The .py stays pure source; outputs never touch the file, so diffs stay clean. Asked in-thread why the detachable-kernel architecture went with .py at all, the author was direct: "I wanted to drop the dependency on .ipynb for this version, so I went with .py files instead. The detachable kernel itself isn't tied to .py." The README argues the same choice from the agent angle, that a notebook is roughly 250 lines of "cell_type" and "outputs" noise where the .py is about 50, and that storing output images as real files lets an agent hand the model an actual image instead of base64 it burns thousands of tokens failing to read. Provenance is modest and stated plainly: MIT, Python 3.11+, 161 commits since a June 12 bootstrap, 13 stars, one fork, three contributors, pip install tithon and code --install-extension rnoro.tithon. The banner at the top of the README says "Status: alpha. It works and it's in daily use, but you will hit rough edges." The last push was August 19, three weeks before the Show HN.

Reach for it if you run long jobs in notebooks on a machine you SSH into, which is most people training anything; it replaces the tmux habit you adopted because the notebook kept dying, and it replaces nothing you are currently paying for. Delete the log file you tail in a second window because you stopped trusting the cell output. Tradeoffs: it is Unix-only because the daemon uses unix domain sockets and setsid, with WSL the recommended answer on Windows and native Windows unsupported; the daemon and the extension must share TITHON_HOME on the same host, which a Tunnel or Remote-SSH satisfies for free but a laptop-to-remote-daemon setup does not, leaving you to forward the socket yourself; the journal is append-only SQLite, so a months-long session is a file that grows and the README does not say who prunes it; and the top-voted reply in its own thread is a flat rejection of the premise — "Nah, this is working backwards," from a commenter who would schedule sit-downs with anyone on his team doing this instead of using a job runner, which is a fair description of the fork in the road this pick sits on.

This is the one that made the naming collision visible, and it is also the most opinionated thing on the slate about what unattended work is allowed to be. Nightshift (MIT, created September 7, 37 stars, one fork, 14 commits, sole committer umairnadeem, Show HN by tcbrah at 10 points and 15 comments) sets two timers on your machine: nightshift-nightly runs once at 5:12 in the morning with up to eight hours to finish, and nightshift-review runs every two hours at seven minutes past with a 70-minute cap. The nightly run walks ten jobs one at a time — security, bugs, readability, maintainability, performance, conventions, conventions-followup, architecture, smoke-tests, issues — and each is a single markdown page of plain sentences you are invited to edit. The security page looks for "real holes a bad actor could use. Not 'maybe someday' worries." The performance page says "slow spots people feel. It measures first." The smoke-tests page says "a few calm tests that check the app still opens. Usually does nothing." The safety model is four constraints and it holds them tightly: "It only ever opens pull requests. Nothing pushes to main. Nothing merges by itself." Before any push, a guard script checks every file on the branch against every file in every open PR — gh pr list --state open --json number,title,files caps at 100 files per PR, which the rules acknowledge, naming the guard script as the real source of truth — and if the only good change needs a contested file, the job does nothing and names the PR that blocked it. The guard's output goes into the PR body under a Merge-conflict guard heading. Missed nights are skipped rather than caught up, which on systemd means leaving Persistent off, so a laptop that was asleep does not wake up and start rewriting your repo at 11 a.m.

jobs/_common.md is the document worth reading even if you never install this, because it is the clearest statement of the unattended-agent contract anyone shipped this week. It opens: "You run alone at night. No one will answer you. Never ask a question. Never stop to confirm. Finish the job." Then the rules that make that survivable. Read the repo's own CLAUDE.md, AGENTS.md, CONVENTIONS.md, CONTRIBUTING.md first, and "they win over these job files." Read what the owner said on recent closed PRs, because "a PR that was closed but not merged tells you what not to do again." Run the repo's checks and "never weaken or delete a check to make it pass." "One clear change beats five small ones. No change beats one weak one." "Do not delete code just because nothing uses it yet" — design tokens, icons, shared interfaces are often kept on purpose — and "never tighten a dead-code checker's ignore list to force those deletions." "Odd things are often on purpose"; if nothing explains a strange pinned version, leave it and ask in the report. "When something goes wrong, let it fail out loud. Do not add code that hides errors." The setup story is the part people are split on. The README's instruction is one sentence you paste at your own agent — "Get github.com/openslop/nightshift and set it up for my code at ~/code/my-app. Read SETUP.md there and follow it" — and SETUP.md is addressed to the agent, not to you. A commenter objected that "every instruction step in the README is just 'Ask your agent to do it'," which makes the system harder to understand and "dumbs down users." The author's answer is the design, stated cleanly: "that's the neat part, there is no prescribed system or code. your agent decides the implementation which you control, the repo is mostly natural language (save for the presentational tui)." Asked whether the agent gets better over time, he says it already does: "it learns from closed PRs and feedback on what changes are high value vs not," which is _common.md step three and not a model update.

Reach for it on a repo with real CI where you would actually read four PRs over coffee; it replaces the backlog of small cleanups you keep not doing, and it replaces nothing you are paying for beyond the agent tokens it will spend nightly. Delete the "tech debt" label you have been using as a place to put things. Tradeoffs: fourteen commits, one committer, four days old, and the organization behind it is openslop, whose other public repos are a video workflow tool and a dataset of 337 faceless AI voiceover YouTube channels, which is either exactly the right sense of humor or exactly the wrong provenance for a thing that opens PRs against your codebase unattended; the eight-hour nightly window against ten jobs is a token bill nobody in the thread quantified and the README never mentions cost at all; the "runs on Windows" badge means a Task Scheduler task that runs the script inside WSL; the guard protects you from your teammates' open PRs but nothing protects you from four plausible-looking PRs a night becoming a review queue you stop reading, which is the failure mode that kills this category; and a repo that is "mostly natural language" is a repo whose behavior you cannot diff, which is a real cost the author is charging you on purpose.

Dagu was on GitHub trending yesterday on 32 stars in a day, which undersells it: 3,898 stars, 329 forks, 3,067 commits, 95 contributors, and a first commit in April 2022, with v2.16.3 shipped September 9 and four releases in the preceding eleven days. It is the oldest thing on this slate by three years and the only one whose problem statement has nothing to do with agents, which is why it belongs here — it is the mature version of the question the other four are asking. The README's argument is a cost comparison and it is honest about all three alternatives. "cron runs commands, but gives you no dependencies, no retries, no history." Airflow orchestrates, "but you operate a platform for it (scheduler, metadata database, workers, a Python environment), and your jobs get rewritten as @dag/@task framework code." Temporal gives durable execution, "but your business logic moves into its SDK and programming model." Then the sentence the whole project hangs on: "You wanted to schedule some jobs. Now you operate a second system, and the orchestrator lives inside the code it was supposed to serve." Dagu's answer is that workflow structure is configuration rather than code: order, dependencies, retries, schedules, and human tasks live in one YAML file next to your scripts, and the engine is a single process. The test it sets for itself is falsifiable and unusually clean — "Your scripts never import the orchestrator. Delete the YAML and they run exactly as before." Install is brew install dagu, an installer script, npm install -g --ignore-scripts=false @dagucloud/dagu, a PowerShell one-liner, a Docker image, or a Helm chart. Steps can be shell commands, Docker containers, Kubernetes Jobs, or remote commands over SSH, and there is a built-in MCP server for inspecting workflows and runs, maintaining wiki pages, applying changes, and controlling runs, which is how a coding agent ends up operating your scheduler without anyone writing an integration.

The state model is the interesting engineering decision and also the limit. Dagu stores state in local files: no external DBMS, no message broker, a built-in web UI, runs on Linux, macOS, and Windows, and the stated target is on-prem, air-gapped, edge, or cloud, scaling "from a single node to a fleet of workers" through queues, concurrency limits, resource limits, and workers that spread execution across machines. The throughput claim is stated with its caveat attached — "a single machine can run thousands of workflow runs per day. Actual capacity depends on CPU, memory, disk, and workflow shape" — which is the right shape for a number nobody can verify from a README. Two disclosures sit right next to the install commands rather than buried: the Docker quickstart notes it "does not expose the host Docker daemon to Dagu," that container: steps need a separate setup, and that "mounting the Docker socket grants workflows control of the host daemon"; and the embeddable Go API is flagged as "experimental and may change." The licensing is the thing to read before you build on it. Dagu is GPL-3.0. LICENSING.md draws the line at embedding: running the CLI is different from "importing the embedded Go API into another distributed binary," applications that link the package and ship the result "should evaluate GPL obligations for the combined work," and "commercial embedding rights are not granted by this repository" — they require a separate written agreement, with contact@dagu.sh as the door. The dagucloud organization was created in April 2023, lists Japan, and runs a hosted demo and a sponsors program. That is a company, and the license is the business model, stated in advance rather than discovered later.

Reach for it when you have four cron lines that depend on each other and a Slack channel that is your only run history; it replaces the crontab plus the wrapper script you wrote to email yourself on failure, and it replaces an Airflow you have not installed yet. Delete the shell script whose entire job is retrying the other shell script. Tradeoffs: GPL-3.0 means a scheduler you can run freely and cannot quietly bundle into a proprietary product, and the commercial path is an email, not a price page; file-backed state is what makes the single binary possible and is also what you inherit when you need durability guarantees across a node loss; YAML as the structure layer is a real ceiling the moment your control flow stops being a DAG; the built-in MCP server means an agent can start, stop, and edit your production workflows, which is either the point or an attack surface depending on who holds the token; and four releases in eleven days on a four-year-old project is healthy velocity and also a reminder to pin the version rather than curl the installer in CI.

This one has been circling our pool since August 31 and never earned a pick, mostly because "agentic research platform" is the most hype-saturated phrase in the vertical. The repo underneath is more specific than the category. OpenResearch (MIT, 1,048 stars, 78 forks, 323 commits, five contributors, first commit June 7, pushed this morning) is a local-first desktop app and CLI that runs Claude Code, Codex, or OpenCode as research agents. Install is curl -LsSf https://openresearch.sh/install.sh | sh then orx up, which opens a dashboard on http://127.0.0.1:4791. The three claims worth checking are structural rather than about model quality. First, parallelism has an isolation story: "Give each research direction an independent agent session and isolated git worktree," so two ideas do not fight over a working tree — the same worktree pattern coding harnesses adopted this year, applied to experiments instead of features. Second, the experiment tree is git-native: "Track variants in a git-native experiment tree; every run receives an immutable archive of its recorded commit," which means a result points at the exact source that produced it rather than at whatever the directory contained afterward. Third, and this is the pick's actual reason to exist, that commit is the unit of portability: "The same committed source snapshot can run locally, over SSH, or on Slurm, Kubernetes, Ray, Hugging Face Jobs, Modal, Tinker, and managed OpenResearch compute. Publishing the repository is not required." orx up --remote user@host runs the workspace next to remote GPUs while you drive it from a browser on your laptop, with SSH config aliases and custom ports supported. There is an orx install-skills that drops an OpenResearch skill into supported coding agents, and a CLI surface — orx runs, orx logs, orx exp run, orx discover keyword, orx paper <arxiv-id-or-doi> — that is scriptable without the desktop app.

The two disclosures in the README are the reason this is a pick and not a footer line. The first is a security caveat stated in the same paragraph as the feature it undercuts, in the docs rather than in a SECURITY.md nobody opens: "The remote service binds to loopback and has no application-level authentication, so other users on that host can reach it." On a single-tenant cloud box that is a shrug. On a shared Slurm login node — which is the exact deployment the sentence above it advertises — that is every other user on the cluster holding a control plane for your agent sessions, and the honesty of putting it there does not make it less true. The second is telemetry, described with unusual precision: official release builds send opt-out coarse usage events tied to a random installation ID, and the exclusion list is enumerated rather than gestured at — no code, prompts, file contents or paths, repository names, tokens, emails, or project and experiment identifiers — with orx telemetry off, orx telemetry status, and a per-command --no-telemetry, and source builds sending nothing at all. The local-by-default claim is similarly bounded: SQLite on 127.0.0.1, creating a project or launching a run does not publish your code, and the openresearch.sh account exists only for organizations and managed compute. The autoresearch mode is the part to hold at arm's length — "propose an idea, change the code, launch an experiment, inspect the evidence, and decide what to try next," with multiple agents exploring in parallel — because nothing in the repo measures whether that loop produces research or produces volume, and the experiment tree is a ledger of what happened, not a judgment about it.

Reach for it if you are already running experiments on a cluster and losing track of which commit produced which number; it replaces the spreadsheet mapping run IDs to branch names, and it replaces nothing you pay for unless you opt into managed compute. Delete the directory called exp_v3_final_ACTUAL. Tradeoffs: the remote service has no authentication and says so, which makes --remote fine on a box you own and a bad idea on a shared login node; Windows needs Git for Windows and is "still in beta"; five contributors and 323 commits behind a tool that will be holding the provenance of your results is thin, and provenance tooling is exactly where you feel thinness late; the managed-compute account is the commercial hook and the local mode is genuinely complete without it, which is the honest version of this business model but still the direction the product will be pulled; and an experiment tree that makes it cheap to launch forty variants is a tool that will happily record forty variants of a bad idea.

Every pick above assumes the work ends up somewhere else, and then quietly assumes you can get it back. syq (MIT, Rust, 30 stars, one fork, four contributors, first commit August 25) is the pick for that last hop, and it was the busiest Show HN in yesterday's pool at 41 points and 47 comments. The headline feature is speed, and the benchmarks page is specific: 159.1 MB/s in 6.75 seconds against rsync's 18.0 MB/s in 59.5 seconds for a large file from Germany to the US; 3.77 GB/s in 4.56 seconds against cp at 971.9 MB/s in 17.7 seconds for a local copy of 16,000 files and 17.18 GB on ext4; 19.2 MB/s in 5.47 seconds against cp at 2.9 MB/s in 36.1 seconds for 25,000 small files over NFS; and 6.28 seconds against rsync's 12.1 for checking 100,000 unchanged files. The author credits parallel connections, direct encrypted TCP where available, and a persistent connection that skips round trips SSH ControlMaster still needs. But the feature that earns the pick is the topology, not the throughput. syq persist connect server run on your desktop means the laptop opens and maintains the connection; after that, from a shell on the server, syq cp results --to @laptop pushes files down it. "It needs no SSH server, public address, or incoming network port." Anyone who has finished a training run on a GPU box and then spent ten minutes arranging a way to get a 400 MB checkpoint onto a laptop behind NAT knows exactly what that removes. There is a matching syq exec --on @laptop --cwd work/project -- cargo test, which runs a command on your desktop from the server and streams output and exit code back.

The approval model is where this gets interesting for anything unattended, and the docs are refreshingly blunt about where containment stops. Incoming copies wait for approval on the laptop "before it can inspect or change destination entries," and --root containment is real: all incoming copies must stay inside that directory, absolute paths and .. are rejected, and symlinks cannot lead outside it. Then the sentence that should slow you down: "The receiving --root and copy limits do not contain commands." Approved commands run as your local user with access to your credentials, and the docs add the second-order warning most tools omit — "build tools and scripts can execute code from their input files; approving a displayed command does not establish that those files are safe." Requests expire after five minutes, a dismissed prompt never grants permission, and interrupting cancels execution but "cleanup handlers do not run." The automatic-approval mode is documented with its cost stated: it "trusts all processes running as the connected server accounts, including for overwrites." On honesty about the headline, the author gave ground in his own thread. Several commenters objected to "better than rsync"; he said he regretted the phrasing and should have written "better than rsync in some respects," and disclosed the specific gap: "syq doesn't currently implement rsync's delta merge algorithm, which allows it to avoid copying data already in the destination file but at a shifted offset." The docs list the rest — rsync filter rules, hard links, ACLs, xattrs, and sparse files are unsupported, with the advice to "check rsync compatibility before substituting it in an existing script."

Reach for it when the machine doing the work is not the machine you are sitting at, which is the premise of everything above; it replaces the scp incantation and the temporary port forward, and it replaces nothing you are paying for. Delete the S3 bucket you created only as a way to move one file. Tradeoffs: 1,254 commits in seventeen days across four contributors is either enviable focus or a build pace worth understanding before you put a file-mutating tool on every box you own, and the thread's skeptics landed on trust rather than features for exactly that reason; no delta merge means an append-heavy large file that rsync would patch cheaply gets recopied; Linux and macOS only, x86-64 and ARM64; the overseas benchmark's own note says "files stay in memory, so this tests the connection rather than disk writes," which makes 8.8x a network number rather than an end-to-end one, and the benchmarks page discloses little else about hardware or network conditions; and syq exec is a command channel into your workstation from a server, gated by a five-minute prompt and nothing else, which is a fine trade when you are watching and a bad one at 5:12 in the morning.

Also on the desk. So you want to use OpenRouter? (213 points, 30 comments) is the most useful thing in yesterday's pool that is not installable, and it is evidence for the picks above rather than commentary on them: eighteen million messages through an iMessage assistant, and the finding is that the same weights are not the same product. "First-party DeepSeek: 90% GPQA, 81% TAU. DigitalOcean, same weights: 75% and 58%." One provider's Qwen vision endpoint "read a K as an R, called red blue" while other hosts of identical weights did not. Reasoning-effort settings are respected by most providers and ignored by several, named. The fp4 hosts "land in the middle of the fp8 pack," so the precision label does not predict quality. Reasoning models return null content with "345 completion tokens, HTTP 200, nothing to show the user." And rate limits are keyed to IP: two providers "worked perfectly from my Mac for DeepSeek V4 Flash, but 429'd nearly every probe from my infra," which is the sort of thing you discover at 5:12 in the morning when nobody is watching. Nine coding harnesses vs. your laptop (118 points, 37 comments) tried to answer the local-hardware version of the same question and mostly demonstrated how hard the measurement is — one commenter reported a harness taking twenty minutes to respond on a 32 GB laptop where llama.cpp answered immediately on the same hardware, another found Codex faster and more token-efficient than the harnesses claiming to save tokens, and the author conceded the Notion hosting was a mistake. NVIDIA/garak (Apache-2.0, 9,188 stars, 4,611 commits) trended again: pip install -U garak, twenty-plus probe modules from promptinject and leakreplay to packagehallucination, and the most mature unattended red-teaming harness in the pool by an order of magnitude. egma (117 stars, 1,696 commits, Show HN at 14 points) builds regression suites of simulated voice conversations and is the testing rung for agents that talk; it supports LiveKit and Retell only, and says so. hyperresearch (MIT, Python, 2,223 stars) is OpenResearch's neighbor pointed at the web instead of the cluster — agents collecting and synthesizing research into a persistent searchable wiki — and has not been pushed since August 4. mesh-llm (Apache-2.0, Rust, 3,375 stars) and cuda-oxide (Apache-2.0, Rust, 3,260 stars, a Rust-to-CUDA compiler from NVlabs) were the Rust trending rows, both about putting the compute somewhere you control. OpenFlux (GPL-3.0, Go, 936 stars) is a TCP tunnel with pluggable transports, which is syq's problem solved at a lower layer and with a different threat model. On Product Hunt, Jackalope put Codex, Claude Code, Grok, and OpenCode in one workspace running tasks in parallel git worktrees — the same isolation primitive as OpenResearch, aimed at features instead of experiments, free during early access with Windows builds still in testing; Cadenya is the hosted version of the agentic loop these five run locally; chat-recall is "Ctrl+F for every conversation you've had with an AI," which is Tithon's journaling problem one layer up; TIM PG anonymizes sensitive data before you paste it into a model; and Raycast 2.0 shipped, last covered here on July 2. Botbin (Show HN, 9 points) is a pastebin for agent artifacts, which exists because the artifacts now outlive the session that made them. Two benchmarks published themselves as products: Kooboo served 5,000 dynamic sites from a 2-vCPU, 4 GB VPS at 99.97% success and a p95 of 1,431 ms, and disclosed that identical cloned sites do not represent a diverse production workload — which is the caveat most vendor benchmarks leave out; and Benzi returned with a harness claimed to beat Claude Code, its second Show HN since August, still a leaderboard hosted by the entrant. Elsewhere: Anthropic's September threat-intelligence report (143 points, 209 comments), the OpenAI Agents API (277 points), a Forgejo RCE rated critical at 194 points that is worth patching before you point any nightly agent at a self-hosted forge, and Shopify moving from React Native back to Swift and Kotlin at 1,109 points, which is the day's loudest reminder that the most consequential engineering decisions still get made by people sitting at the keyboard.

Verification notes: star, fork, commit, contributor, license, release and first-commit figures are from the GitHub API on 2026-09-11; commit counts use the per_page=1 Link-header page trick, and first commits are the last page of that same query. HN points, comments, timestamps and comment text are the Algolia API (/items/<id> for full trees, /search for metrics). The four Nightshifts: toolshedlabs-hash/nightshift (MIT, Shell, 5 stars, created 2026-07-23, last push 2026-08-03), Shaurya-Sethi/nightshift (MIT, Rust, 10 stars, created 2026-05-20, Show HN 49643048 at 2 points), openslop/nightshift (Show HN 49648105), and the fourth is a claim by commenter Decimal8765 in that thread, not a repository we located. The collision comment is shaurya-sethi in item 49648105; the README criticism and the "that's the neat part" reply are spidersouris and tcbrah in the same tree; note that the Show HN account is tcbrah while the repository's sole committer is umairnadeem, which we did not resolve. Nightshift's timers, job list, guard rules and quoted lines are README.md, SETUP.md and jobs/_common.md on main; the openslop organization was created 2026-02-23 and its four public repos were read from the API. Tithon's problem statement, architecture, CLI table and alpha banner are README.md on main; the .py-over-.ipynb answer and the "working backwards" objection are the Algolia tree for 49626144; PyPI and Marketplace identifiers are the README's badges, not independently installed. Dagu's alternatives comparison, install commands, Docker-socket warning, performance paragraph and experimental-embedded-API note are README.md; the embedding terms are LICENSING.md; the dagucloud organization creation date and location are the API. An earlier read of a summarized version of Dagu's README reported a known-broken notification path in v2.11.0-v2.11.2; that sentence is not in the README on main today and is not repeated here. OpenResearch's feature table, run-anywhere list, loopback-authentication caveat, telemetry paragraph and Windows-beta note are README.md on main, quoted verbatim. syq's benchmark figures are the syq-bench site; the topology, approval model, --root containment, command-containment warning and automatic-approval caveat are docs/receive.md and exec.html; the "better than rsync in some respects" walk-back and the delta-merge disclosure are the author in item 49644955. Nothing on today's slate was reproduced: four of the five are daemons or schedulers that want a persistent foothold on the machine, and the fifth wants a standing command channel into it, which is not a thing to install from an unattended compose run. Repro count since 08-19: 1 genuine in 13 editions. Machine-facing docs check: docs/SPEC.md on Tithon; SETUP.md, jobs/, review/SKILL.md and CONTRIBUTING.md on Nightshift; CONTRIBUTING.md, LICENSING.md and a full docs.dagu.sh on Dagu; docs/windows.md and docs/local-models.md on OpenResearch; docs/development.md on syq. Seen-before SQL keyed on fetched_at: Tithon, Nightshift, Dagu and syq are all first-time rows in our candidates table and first-time in an edition body; OpenResearch appeared in the pool on 08-31 as alphaXiv/openresearch-cli and on 09-02 under its current name and has never been linked; Raycast was last linked on 2026-07-02; none of today's five [link] URLs appears in any prior edition body. Today's pool was 81: hn:front 30, hn:show 18, producthunt 19, and github:trending 14 rows across four feeds (all 7, go 1, python 4, rust 2) with the typescript feed returning nothing; the github series is 15 → 1 → 10 → 26 → 11 → 11 → 1 → 20 → 12 → 14 → 21 → 15 → 14, and Reddit is dark for the twenty-eighth consecutive week. Scheduler: Thursday's run started on time and authenticated cleanly; the 09-09 and 09-05 no-shows noted in Monday's edition remain unexplained and still produce no alert, because an edition that was never written has no row to age past twelve hours.