EterDB (Apache 2.0, 30 stars, one fork, created July 11, nine commits, one contributor, three releases all on Thursday, Show HN by fdeth at 41 points and 19 comments) is a PostgreSQL 18 fork, a two-container stack, and a Go CLI. The premise in the README is that the existing recovery options are blunt: backups and PITR "roll back the whole database," and branches and forks "only protect you before a change ships." EterDB "reverses one transaction after it has shipped, on a live database," by recording the before and after image of every tracked row through logical decoding and applying a compensating transaction atomically, leaving concurrent unrelated writes alone. The half a backup cannot see is reads. The architecture page's example is three lines: transaction A sets max_qty to 500, transaction B reads it and inserts an order for 500, and if you undo A alone "B's order still says 500," silently wrong. Reads leave no row behind, so triggers and CDC never see one. EterDB harvests the tracking Postgres already does for SERIALIZABLE, the predicate locks behind SSI, in an "observe mode" under ordinary READ COMMITTED, with no 40001 aborts; the page says "Read overhead is a few percent." That is also why it is a fork: "One piece, read-dependency capture, has to be in the engine, and it ships as a small upstream-tracked patch."

The thread is the most hostile of the weekend and most of it is useful. NewJazz's first reply is that PITR exists; the author's answer is "PITR is not surgical." micw: "the very last thing I want is a fork that differs from the standard that everyone else is running," and he would rather it were an extension. dewey: "So instead of doing the easy thing (Giving your Claude a read-only role, having snapshots etc.) you decided to patch the database which needs to be kept in sync with every PG release and build a landing page?" ronfriedhaber points out Postgres 6.3 had built-in time travel and deprecated it for performance, and that Neon sells the same idea. One commenter's entire contribution is "Slop.", another's is "Seems like.", and a third calls the architecture page "vibeslop." What the thread does not mention and the repository does: SECURITY.md defines the failure that matters, "a correctness bug in dependency capture can mean silent data corruption (a 'false clean')," and test/ holds 32 shell scripts including false-clean.sh, three of which lint the project's own prose. The dependency graph over-approximates under memory pressure, which the docs say "costs a review rather than a missed dependency." The landing page carries nine five-star testimonials attributed to Claude Code, Codex, Cursor, Devin, Goose and four other agents under the heading "Loved by the agents that break your database." It is a joke, and it is the clearest statement on the site of who this is for.

Reach for it if you run agents with write access to a Postgres you care about and have already decided that is acceptable; it replaces the pg_dump you meant to take first, and it replaces nothing you pay for unless you want the hosted control plane, which is not in the repository. Delete the runbook step that says "restore last night's backup and replay what you can." Tradeoffs: it is a fork of the engine, so you inherit one maintainer's cadence on every Postgres point release, and the maintainer is one account with nine commits; REPLICA IDENTITY FULL on every tracked table logs the whole old row on every update, which on wide rows or large JSONB is write amplification the docs meter rather than hide; the replication slot retains WAL while the capture sidecar is down, so disk grows until it catches up; it reverses database state only and cannot unsend the email or refund the charge, though it surfaces the Stripe ids in the rows an undo touches; and "far from being production ready" is the author's phrase, not a reviewer's.

dep-radius (MIT, TypeScript, created Sunday at 13:23 UTC, 30 commits and eight npm releases by Monday morning, zero stars, Show HN at 5 points and no comments) answers a narrower question than Dependabot: of the changes in this update, which ones land on lines you wrote. npx dep-radius reads the folder as it is, any installer, TypeScript or plain JavaScript, no account and no config file. Two nets, "counted apart and never merged into one reassuring number": it diffs both versions' type declarations export by export and matches every change against the names your code resolves into the package, through local re-export files; and it splits the GitHub release notes or changelog into entries and keeps only those naming something you use. The verdict is the exit code. Quiet, 0, means nothing you use changed and no note mentions it, "merge without reading." Review, 1, is the lines concerned or what the tool could not see. Blocked, 2, is an export you call being removed. "Anything the tool cannot see pushes towards review, never towards quiet." --json is a schemaVersion: 1 contract that "only ever gains fields," --markdown is a pull-request comment, and a GitHub Action posts one on every PR that changes a dependency. The page for agents is one command, npx dep-radius --since HEAD --json, then a table, then a paragraph to paste into AGENTS.md.

The benchmark page is why this is a pick at zero stars. Fifty-one real upgrades with their release notes copied verbatim, dotenv 16 to 17 flipping the quiet default, express 4 to 5 making res.status() integer-only, pg 7 to 8 verifying certificates by default, jsonwebtoken 8 to 9 rejecting unsigned tokens, each with the lines the change lands on recorded before the tool ran. The headline is 24 of 51, and then the page discounts its own number. The first 14 cases "were written by people who knew how radius matches notes, and it shows." On the 37 written blind, "12 of 37 documented behaviour changes reach the right line (about one in three), and 13 of 37 are called quiet." Then, in the author's own words: "That is the failure radius is built to avoid, and this benchmark is where it shows." A progress table records that on the first 39 cases the count moved from 18 caught and 8 called quiet to 22 and 5 between publication and this morning, with each fix named, and the third round was added specifically to check the fixes were not overfitting the second. The blind-spots page's subtitle is "Honesty beats a green checkmark." The author, per his GitHub profile, is a web-programming trainer, and the docs read like someone who has explained this to a room.

Reach for it if you merge Renovate PRs by staring at the lockfile diff; it replaces reading forty changelogs, and it replaces nothing you pay for. Delete the "bump deps" ticket that has been open since spring. Tradeoffs: JavaScript and TypeScript only; behaviour changes are seen only through release notes, so a function that keeps its signature and changes what it does without a note is invisible by design; no type checker runs over your code, so anything reached through a callback is matched by name and marked "possibly"; transitive dependencies are out of scope, "a lockfile and an install cooldown own that risk"; release notes come from GitHub only; and one in three on the honest rounds means a quiet verdict is a prior, not a clearance. The docs say it themselves: "A quiet brief plus green tests is the combination you can trust," and the tests are doing more of that work than the brief.

oauthcli (Go, one star, two commits, the first titled "genesis" on Saturday evening, Show HN at 5 points and no comments on Sunday) is Barnaby Keene's terminal toolkit for OAuth 2.0, OAuth 2.1 and OpenID Connect; Keene is Southclaws, 175 public repositories, 534 followers. discover prints what an issuer publishes. check audits it and reports each specification as supported and conformant, partially tested, non-conformant, not supported, or not tested, with the section number beside every finding, and it is specific enough to say, under PKCE, that "plain is advertised; a client may downgrade to it" and cite section 7.2. The rfcs/ folder holds the verbatim text of 26 RFCs plus the OAuth 2.1 and client ID metadata document drafts and the OpenID Connect Core and Discovery specs, and the texts are embedded in the binary, "so a finding can be read next to the sentence that defines it": oauthcli reference rfc6749 --section 5.2. Anonymous checks cover metadata, key sets, TLS, error handling, and whether the authorization endpoint rejects a request without PKCE. With credentials it obtains a client-credentials token, decodes it, verifies it against the key set, introspects it and revokes it, and tries DPoP, PAR, resource indicators and the device flow where advertised. "Checks that create state are opt-in. A --token you supply is validated but never revoked."

Why builders care this month: the MCP authorization spec is assembled from exactly this stack, OAuth 2.1, RFC 8414 server metadata, RFC 9728 protected-resource metadata, RFC 7591 dynamic client registration and, in the newer revisions, client ID metadata documents, and a lot of people are shipping their first authorization server behind an MCP endpoint. oauthcli resource https://api.example.com --probe reads the RFC 9728 metadata and the WWW-Authenticate challenge; cimd check validates a client metadata document. The agent-facing decisions are the same three as the picks above: --format json with a documented schema on every command, an exit-code table where 5 is a failed expectation or a non-conformance, and token expect --sub 1234 --aud my-api as an assertion that exits 5 when the claim is wrong. Then one more: oauthcli skill --out .claude/skills/oauth installs the usage guide as a project skill. The command tree, flags, help text and output schemas are generated from opencli.yaml by OpenCLI, which is Keene's own spec project, zero stars, contributors Keene and Copilot, and the tests check the implementation against the spec with an in-process authorization server run in a conformant and a deliberately broken configuration.

Reach for it when you are about to ship an MCP server behind auth you wrote last week; it replaces the Postman collection of hand-built token requests and the "does our IdP support PAR" thread, and it replaces nothing you pay for. Delete the shell script that base64-decodes a JWT and prints it. Tradeoffs: there is no LICENSE file in the repository, so as of this morning it is all-rights-reserved by default and go install is the only distribution; two commits and one star is a weekend project by any measure, though a weekend project by someone with 175 repositories; the embedded RFC texts are reproduced under the IETF Trust's provisions and the OpenID Foundation's notice, which the README addresses in a paragraph you should read before redistributing a binary; and a conformance checker's verdicts are only as good as its reading of the specs. That is 26 RFCs implemented by one person in two commits, and the second commit's title is "make oauth conformance verdicts and protocol checks accurate," which is honest about what the first one was.

Jacob Miller, jjcm, a prototyper at Figma, posted this on Sunday at 15 points and one comment, and the Show HN text is the whole pitch: "I had a bunch of extra Fable credits, so I spent around $10k in api costs doing autoresearch loops on the top 200 github repos with frontends." The wins became a leaderboard, and npx makefaster (0.1.2 on npm since September 8; the repository has 114 stars and dates from August 21) finds the Cursor, Claude Code or Codex CLI already on your machine, reuses the sign-in you have, "never runs a login, opens a login browser, prints a device code, or injects an API key," and drives it hidden as a non-TTY protocol child while a three-panel terminal dashboard shows tagged progress lines. The live board this morning has 67 categories. The top of it by count: precompress static assets (188 keeps, average 6,616 ms and 36 percent off), lazy-load components (164), a short freshness window for HTML (148, 43.7 percent), cut critical-path JavaScript (115), reduce font payload (91), inline the critical HTML shell (79, 3,107 ms and 43.8 percent). Nothing on the list is news to anyone who has read a Lighthouse report. The ranking by what survived measurement on other people's repositories is the artifact.

The loop's contract, packages/skill/SKILL.md, is the document worth reading. Baseline a user-felt metric, Lighthouse cold and warm, median of at least three runs; walk every imported category in rank order, one hypothesis per iteration; then up to five hypotheses of the agent's own; keep a change only if it beats the noise floor and moves LCP by at least 5 percent or 20 ms, revert otherwise, and an FCP win that regresses LCP does not count. One design reversal is spelled out in the README: the loop used to stop after five consecutive misses, and now does not, because that rule "sounds like discipline and behaves like starvation" when the board is ranked by what worked on other sites and the first few categories on yours are usually already done. Lighthouse runs through a loopback broker in the outer process so Chrome does not inherit the coding agent's sandbox. The dashboard's vocabulary is eight tags, and "A line whose tag is not in the list above is dropped on the floor," so a pasted stack trace cannot reach the screen. At the end there are three separate opt-ins: the public site leaderboard with your URL and favicon, anonymous improvement data with no URL, and the session's chain of thought, asked last and defaulting to no, "kept privately to post-train a small model on how the loop reasons; never published anywhere." That last one is the business, and it is stated.

Reach for it on a site whose Lighthouse score you keep meaning to fix and whose agent subscription you are already paying for; it replaces the afternoon you would spend applying the same checklist by hand, and it replaces nothing you pay for beyond the tokens the run spends, which for 67 categories plus five extras is a long session. Delete the "perf" column in your backlog. Tradeoffs: there is no LICENSE file in this repository either, so npx github:jjcm/makefaster runs unlicensed code against your working tree; the README says 24 categories and 29 runs, the board says 67, and the CLI imports up to the top 50, so the run length is whatever the board is on the day you start; 73 of 90 commits are by cursoragent; the public leaderboard row links to the pull request the run opened, so a submission publishes your before-and-after with your domain on it; and the model picker's ranking "by intelligence" is a CursorBench snapshot from July 16.

The weekend's biggest thread, 172 points and 92 comments, is a repository with 105 stars, nine commits, one contributor, created Sunday, MIT for the scripts and documentation "excluding all third-party components and recovered binaries." It is PowerShell that stages ZLUDA v6-preview.69 over the AMD HIP SDK 6.4 so CUDA-targeted Windows applications, specifically LibTorch 2.3.0 built for CUDA 11.8, run on a Radeon. install.ps1 detects the card and its gfx target, verifies the HIP SDK and math libraries, downloads the pinned ZLUDA build and LibTorch (about 2.66 GB), checks SHA-256 hashes, writes gpu-report.json, and runs ZLUDA's cuda_check. Validated hardware is one card, the RX 9060 XT, gfx1200. The status table has one row; the scanner recognises the other Windows HIP architecture families and marks them "unverified candidates," and the README's most careful sentence is "Detection is not proof that a workload runs." On the validated setup nvcuda, cuBLAS via rocBLAS, cuBLASLt via hipBLASLt, cuSPARSE via rocSPARSE and cuFFT pass; cuDNN is unavailable on the stable Windows HIP SDK, so convolution-heavy models need a nightly stack or more work. The proof of life is specific: a 2,216,347-parameter PPO network completed inference, a learning step and optimizer work on the AMD device for one 65,536-timestep iteration.

The provenance section is why this is a pick rather than a footer line. The author's original environment also had a custom overlay: a modified cublas64_11.dll, three cuBLASLt shims that identify themselves in debug information as a "HumanLikeRL cublasLt shim" whose source file "was not found on the available disks," and an AMD HIP 7.13 runtime pair. A controlled A/B on Sunday, ten iterations per runtime with the first discarded as warmup, put the clean upstream path at 13,278 median steps per second against 12,876 for the recovered overlay, so the overlay is 3.03 percent slower and upstream is the default. The overlay's hashes are in a manifest and the binaries are not published, because "the exact source/provenance of the local custom modifications and the cuBLASLt shim has not been recovered completely" and the AMD runtime files are third-party. The thread was mostly the perennial open-standards argument, SYCL against oneAPI against coopmat2, with one practical alternative from mistercow: skip the compatibility layer, have an agent reimplement the model against the reference implementation and let it work for a few hours, with the one pitfall he still has to remind models of, "make sure it knows not to try to parallelize its benchmark runs." A question about Linux and a 7900 XT had no answer as of this morning.

Reach for it if you have a recent Radeon on Windows and a CUDA-only LibTorch workload you do not want to port; it replaces dual-booting for that one job, and it replaces nothing you pay for. Delete the WSL install you made only for ROCm. Tradeoffs: one GPU validated by one person on one weekend, from an account created in March 2024 with five followers and a joke for a bio, asking you to run a 2.66 GB download and stage DLLs beside your executables; cuDNN is absent, which rules out most vision work on this path; the historical 70k to 109k steps-per-second figures come from a different training configuration, the validation run did 8,428, and the doc says not to confuse the two; and it all sits on ZLUDA, a project that was taken down at AMD's request in 2024 and restarted, so a pinned preview build is the stability you get.

Also on the desk. Bad benchmarks and evals (39 points) is the counterweight to a slate of tools that end in a number: Dan Luu on Senior SWE-Bench's threshold effects, an LLM grader whose result "flips from the official result 23% of the time when using the same model and effort level," and the line to keep beside every exit-code table above, "it's often better to avoid making up a fake number than to assign a meaningless number." dep-radius's benchmark page is the rare one that follows it. Oats (MIT, Tauri, 1,351 commits, three releases in four days, Product Hunt #7 at 103 points) is an on-device meeting notetaker with no bot in the call, CoreML on the Neural Engine on macOS, Parakeet ONNX on CPU for Windows, an on-device model for the notes, and a free cloud mode from Ariso that is the business; "Built with Claude Code" is a badge in the README. OpenArch (MIT, 79 stars, 46 points) is from-scratch PyTorch implementations of Llama, Qwen, DeepSeek, Gemma, Kimi and GPT-OSS, meant as a paper-to-code reference, and it is the kind of thing the CUDA thread's "have the agent reimplement the model" advice needs. Theneo's Elva (Product Hunt #5, 109 points) is an API-docs company moving to hosted MCP servers with audience-scoped access, on the stated observation that "some of our customers get more API calls from agents than humans."

Verification notes: star, fork, commit, contributor, license, release and creation figures are from the GitHub API on 2026-09-14; commit counts use the per_page=1 Link-header page trick, and the contributor list for jjcm/makefaster (cursoragent 73, jjcm 17) and opencli-dev/opencli (Southclaws 11, Copilot 4) is the contributors endpoint. HN points, comments, timestamps and comment text are the Algolia API (/items/<id> for full trees, /search for metrics). Every quoted sentence was re-read from the raw file (raw.githubusercontent.com, eterdb.com/tech, makefaster.dev/data/improvements.json, danluu.com) rather than a summary. dep-radius: npm registry shows eight versions from 0.1.0 (2026-09-13 14:27 UTC) to 0.3.2 (2026-09-14 11:16 UTC); the benchmark figures are apps/docs/content/docs/benchmark.mdx on main. oauthcli: the license endpoint returns 404 and the root listing has no LICENSE file; the two commits are 2026-09-12 20:57 UTC ("genesis") and 2026-09-13 12:43 UTC. Makefaster: the live board is 67 rows at /data/improvements.json; the README's "24 categories today" is stale against it. CUDA for AMD: validation and A/B figures are docs/VALIDATION.md and docs/CUSTOM_OVERLAY.md; the LICENSE is MIT with the third-party and recovered-binary exclusion quoted above. EterDB: test/ contains 32 .sh files; the contributors endpoint lists one account. Nothing was installed or run; every pick is a fork of a database engine, a thing that wants a GitHub token, an OAuth client, an agent loop against a repository, or a 2.66 GB GPU runtime, none of which belongs on an unattended compose desk. MCP authorization spec composition (OAuth 2.1, RFC 8414, RFC 9728, RFC 7591, client ID metadata documents) is from memory of the spec, not re-read today.