FAQ

A tooling-first AI newsletter — with a show alongside it — for people who care how AI products are used, built, adopted, and improved. Every day it tracks what roughly 800 open-source and commercial AI tools actually shipped and writes up the features that matter, with the commands to run them. It focuses on the in-the-trenches work — the development and use of the tooling and products that protect organizations from AI threats — rather than high-level talking points, vendor promises, and generalizations. The easiest way to reach me is by email.

Same account, different beat. The Cyber Toolchain is this project's sibling site, tracking cyber tools the same way this one tracks AI tools — release notes, features, and usage examples, read so you don't have to scan them yourself. Sign in with the same email on either site and your plan carries over automatically, so there's nothing to set up twice. They stay two separate publications on purpose, rather than merging into one generic tech newsletter: each stays in its own lane, and each newsletter only ever covers its own tools. This site is newer and still building out its coverage, starting with a weekly edition — expect more series to come online as the roster grows, the same way Cyber's did.

Because keeping up with AI tooling is a full-time job nobody has time for. Release notes are scattered across hundreds of repos, changelogs, and vendor docs sites, most of it routine bug fixes; the genuinely useful new capability is buried in there somewhere. This reads all of it every day so you don't have to, and tells you what changed and how to use it.

The same gap exists in audio. There are plenty of great AI shows — Risky Business for news, Defense in Depth for industry topics, Inside The Network for the business side, No Password Required for practitioner personalities. They're all excellent and I listen to them. But none focuses heavily on the tooling and products used to defend organizations — the boots-on-the-ground work that gets overlooked in favor of high-level talking points that lack the practical context you can actually take back and apply. I want to help solve for that.

Primarily technical coverage that keeps you up to date on the latest open-source and commercial tools, their features, and the problems they solve. Expect:

• A daily newsletter of what shipped, with the new features explained and real usage examples — plus a weekly highlights edition and a weekly product-docs edition.
• A page per tool with its release history, activity, licensing, and recorded command runs you can read the real output of.
• Video demonstrations of tools and their use-cases on the show, and conversations with the people who build them.
• How tools work under the hood — the underlying technology and how they're deployed.
• How to build your own tools and prototypes through vibecoding and agentic engineering.

We're at an important inflection point in the industry, driven by several forces:

• The changing nature of attacks due to AI. Vulnerabilities that once took weeks or months to find and exploit surface faster; phishing no longer requires native language skills; malware no longer requires deep CS and OS-internals expertise; and new impersonation attacks like voice and video deepfakes have emerged.
• Agentic engineering (AI coding agents) lets vendors, developers — and attackers — build AI tooling far more easily.
• # TODO(jon): this paragraph is cyber's market thesis, mechanically # translated. It needs rewriting for AI tooling — the $10.5T cybercrime # figure is not this product's argument. An increasing regulatory environment, as AI adoption outpaces governance and the EU AI Act, sectoral rules and procurement reviews start dictating what teams may ship.
• Investment to fuel AI-company growth has ramped back up toward 2021 levels.
• Budget compression — most organizations are doing more with less and need to get more value out of their tooling to defend their environments.

And more personally: by leveraging agentic tooling for automation, I finally have the capacity to run a daily newsletter and a show alongside a full-time job — something I couldn't have accomplished before.

The AI Toolchain is for people who care about how AI products are used, built, adopted, and improved. It's for:

• Practitioners who want to discover new tools and features and learn how to leverage them to solve real AI problems.
• AI leaders who want a practical view of where tooling is headed and what their buying options are.
• Product managers and leaders who care about building better AI products.
• VCs and advisors looking for emerging categories, technical founders, and product signals in AI.
• Open-source maintainers building useful tools who want to share their work with the AI community.
• Startup founders who want to showcase their tools and learn from other builders navigating product, GTM, funding, and customer adoption.

This starts as a one-person team (with a full-time job), so I'll unequivocally need help from the AI community to drive it forward. Where you can help:

• Recommend tools (FOSS or commercial) and use-cases worth covering — including tools you understand the least but would like to learn about.
• Share redacted demo videos of tools you're using and the use-cases you're solving. Let's crowdsource this!
• Make introductions to startups and maintainers you think would be valuable additions to future episodes.
• Give honest feedback on the newsletter and the show — what sucks, what's great, and how to make it better.

Just email me. The more context you provide — along with contact info, if you'd like me to follow up — the better.

If you're a FOSS maintainer, or a Seed or Series A AI startup with users and a solid product you can discuss and demo across your top three use-cases, I'd be interested in having you on. Reach out by email. If you're Series B or later, see sponsorship below.

We love sponsors — they keep shows alive and growing. Sponsorship here isn't a traditional ad slot; we want to keep the show ad-free as best we can. Instead, a sponsor gets a full dedicated episode where the audience learns about your tools and use-cases and sees a recorded demonstration — just like any other tooling episode, so it stays aligned with our vision. Sponsorship is for companies Series B and up; we'll happily have Seed and Series A startups on without it. For a different kind of sponsorship, reach out by email.

More than it looks like. Building the software behind the site — the pipeline that watches ~800 sources, the newsletters, the tool pages, the analytics, the capture sandbox — has taken over $10,000 so far, and it keeps costing money every day it runs: hosting, storage for the archive of everything ever fetched, and the compute behind the summaries and analysis. None of that is covered by ads, and it's paid out of pocket.

If this is useful to you, the two ways to keep it going are sponsorship — a dedicated episode rather than an ad slot, see How can I sponsor? above — and a supporting subscription. Both are arranged directly: reach out by email.

The AI Toolchain is created and hosted by Jon Schipp. See the About page for the full story.

Five, each a separate series with its own numbering. They are named for what they do to the stream of releases — tail, grep, head, diff, uniq. The ISSUE dropdown on any issue page jumps between them, listing the five most recent issues of each; the archive has every issue ever published.

• Tail — the daily release firehose, every weekday, usually by 7:30am ET (11:30 UTC). Everything that shipped across the watchlist and the features each release brings, with runnable commands where they help. A quiet day publishes nothing rather than padding an issue. Free to read on the site; the delivered edition also carries the day's documentation changes.
• Grep — only the tools you run. The same coverage as Tail, narrowed to the tools and categories you pick. You can hold several, each with its own name, its own list and its own email, so one can cover the stack you run and another the vendors you are watching. It has no fixed schedule on purpose: filtered to one person's stack most days are empty, so a Grep arrives when its tools ship and stays quiet otherwise. It rides the daily, so on a day it has something it lands at the same time — usually by 7:30am ET (11:30 UTC). Delivered only — there is no web edition.
• Head — the week's top picks, Fridays, usually by 1pm ET (17:00 UTC). Our chosen highlights from everything that shipped, each with a short "why it matters". Five picks; Practitioner and above can switch it to ten. Free to read on the site, and the one newsletter delivered free — no card.
• Diff — what vendors changed and didn't announce, Wednesdays, usually by 12:30pm ET (16:30 UTC). Meaningful additions to the product documentation and API reference pages of the tools we watch. Subscription only — the newsletter page carries one sample entry.
• Uniq — how vendors reposition themselves, monthly. The category a vendor claims, the buyer they name, the plan names and prices on their pricing page, and the language the whole market is picking up or dropping — counted across the cohort, because one vendor rewording its hero is gossip and nine doing it in the same quarter is the market moving. Researcher and Business. Delivered only — your back issues are listed on your account page. Not sending yet.

Every Tail and Head issue is free to read, with no account, and so is every chart on the analytics page — every score, bar and figure, with the methodology published so you can re-derive them. The web edition of an issue covers the releases; the delivered issues add the day's documentation changes and further usage examples. What a subscription adds is delivery, filtering to your own stack, and additional data signals and analytics published nowhere else — who is slipping, what keeps breaking, and where a market is moving. Some chart labels are held back on the free tier; see Why are some chart labels hidden? below. On top of that, one newsletter is delivered free:

• Free — $0, no card. Head lands in your inbox every Friday: our chosen top picks from the week. Unsubscribe in one click.
• Practitioner — $10/month, or $100/year — a 17% saving. Adds Tail daily, Diff weekly, and Grep — the same coverage narrowed to the tools and categories you actually run, so you stop scanning a 100-release firehose for the six things you care about. Track as many tools as you like, and read Head ten picks deep instead of five.
• Researcher — from $20/month, or $200/year — a 17% saving. For questions bigger than one issue. Every chart names its tools and categories instead of masking them, including the defect analysis drawn from every release note we have collected — which failure kinds a tool keeps shipping fixes for, how concentrated they are, whether repair is crowding out new work, and whose fixes don't hold. Alongside that: query the tracked corpus from your own scripts and agents over an API and MCP server, and get new findings as they surface rather than in a quarterly report. It also adds Uniq — how the vendors we watch reposition themselves, monthly — which is not sending yet.
• Business — $1,000/month, starting at five seats. Everything in Researcher across the whole team, plus a shared watchlist we build with you. Requires a company email address.

Four things are the exception to "free to read": Grep exists only as delivered email, because a per-subscriber filter has no meaningful web page; Uniq is delivered email too, with your own back issues listed on your account page; Diff is subscription-only with a single sample entry shown on the newsletter page; and the analytics charts that rank individual tools show everyone the shape and the numbers but not the names.

No — it's the design. Each Grep is a complete issue on its own, so you can forward one to a colleague or route it to a team channel without it having holes where the overlapping entries would be. A release that matches two of your lists appears in both. Every entry in a Grep preview carries the reason it's there ("matched: cloud-AI"), so you can see where the overlap comes from and narrow one of the two lists if you'd rather see each release once.

Most likely it's too narrow. Open it on your account and choose See an issue — the day strip shows how often it would have fired over the last month, and names the category that would fix it if the answer is "almost never". Two other causes worth ruling out: a tool you follow may have been renamed, which the account page flags on the Grep itself, and a paused Grep sends nothing while it's paused. A Grep with nothing to report sends no issue at all rather than an empty one, so quiet days are silence by design.

Yes, on any plan including the free one. Send me a test on your account puts a real issue in your inbox on demand, rendered in whichever palette you picked — the same renderer that produces the real thing, so what you see is what will arrive. It sends the Head edition you read, five picks or ten, and the picker beside the button offers the other one if you want to compare before choosing. Paid plans can also preview any Grep on the site, built from that Grep's own settings against the last month of releases.

Yes. Tick I'm taking a break on your account and every newsletter stops, including the paid ones — your selections are kept, so unticking it starts them again on their normal schedule with nothing to set up. A subscription keeps running while you are paused; a break is about what arrives, not what you pay for, so cancel instead if that is what you want. Switching every newsletter off individually does the same thing to your inbox, with one difference: an account that has gone silent that way gets a note once a quarter asking whether it was meant. A declared break gets no note at all.

Tail every weekday, usually by 7:30am ET (11:30 UTC). Grep rides the daily, so on a day your tools ship it lands at the same time. Head on Fridays, usually by 1pm ET (17:00 UTC). Diff on Wednesdays, usually by 12:30pm ET (16:30 UTC). Uniq is monthly and has no scheduled time yet — it is not sending.

Those are outside times, not promises: each issue is generated when its job runs, and how long that takes depends on how many sources answered and how much they shipped. The times above are measured from recent runs and rounded up, so most issues arrive earlier. A quiet day publishes nothing at all rather than padding an issue — silence is a real outcome, not a delay.

Each week the releases from that week are compared against each other and at most ten are picked, favoring depth (a substantial capability, not a minor flag) and differentiation (something that changes what the tool can do). The published issue and the free email carry the top five; a Practitioner plan or above can switch Head to ten on the account page and read the same week five tools deeper. The bar does not drop for the second half — most weeks fewer than ten clear it, and the issue says so. A tool featured one week is held out of the next one, however much it ships — the shortlist is there to widen what you see, not to track the loudest vendors week after week. If nothing clears the bar in a given week, no issue ships and the series doesn't burn a number on a filler edition. The picking is done by an LLM — see Is this AI-generated? below.

Yes. On a Head issue, the "SHARE THIS WEEK" buttons download a ready-to-post PNG of that week's picks — Top 5 gives a square image of the week's five highlights for a feed post, Top Pick a portrait image of the single standout for a story, both branded and sized for social. On the tools page, open any tool and use the ▽ share button in the modal to download a card for that single tool — its category, version, GitHub stars, release count, and a 12-month release-cadence chart. The images are rendered in your browser; nothing is uploaded. To point someone at a specific tool in an issue, use the ⧉ Share button next to that tool's name in the newsletter or highlights — it copies a direct link to that entry (on a phone it opens your share sheet instead).

For Head, yes at the same edition — five picks by default, or ten if you have switched Head to ten picks on the account page, in which case the email carries all ten and links to a private page with them. For Tail, the delivered edition carries more: the website version is releases only, while the emailed issue also folds in that day's product-documentation changes — capabilities vendors shipped without announcing them.

That is the difference a subscription buys, alongside filtering. The same documentation signal is also collected into Diff, the dedicated weekly roundup, so subscribers see it inline each day and again as a digest on Wednesdays.

It watches the official product documentation of the tools on the watchlist — not just the front page, but the tree of feature and product pages beneath it — and their API reference pages, where a new endpoint, a renamed parameter or a retired field shows up before your integration breaks. It surfaces what's newly added: brand-new pages the vendor just published, plus new capabilities, settings, endpoints and changed behavior within existing pages. It deliberately does not report:

• Changelogs and release notes. Those are product releases, not documentation — Tail already carries that signal, and reporting both would double-count it.
• Wording, grammar, and formatting edits. Only added content that describes what the product now does is worth an entry.

Docs changes are a leading indicator: capabilities often land in the docs before they're announced anywhere else.

When a vendor changes a documentation page, we compare it against the last version we captured and show you the changed text itself — the lines added and the lines removed, in place. The removals are often the part worth seeing: a retired option, a lowered limit, a default that quietly moved. Every subscribed plan gets the changed text itself inside the delivered issue, not a description of it. The same applies to API changes, where we show the before and after of the endpoints that moved — the parameters, their types, whether they became required, and the response codes that appeared or disappeared.

Long changes are trimmed to keep an issue under the size limit mail clients impose, and the issue says how many were shown in full and links the page for the rest.

Subscribe by email from the homepage — the signup is at the bottom. Head is free and needs no card; the paid plans add Tail, Grep and Diff, and Researcher adds Uniq. If you'd rather use a reader, the Feeds page lists everything you can follow: the combined RSS feed at /rss.xml (Tail + Head), a separate RSS feed for each series on its own (/newsletter/releases.xml, /newsletter/highlights.xml, /newsletter/docs.xml), one feed per tool category, and per-tool feeds. Diff is deliberately kept off the combined feed — it tracks documentation changes rather than releases, so it would drown out the release items — but it has its own feed if you want it. The Feeds page is not in the top nav; find it from the search bar (⌘K) by typing "feeds", "rss", or "subscribe".

The Tools page is the full watchlist — every tool being monitored, not just the ones that shipped something recently. It's the place to browse the landscape rather than the news.

• The search box above the table searches everything at once — tool name, vendor, category, source and description. Type kubernetes to find every tool that works on it, whichever column says so. Several words narrow rather than widen. It combines with the column filters below.
• Every filter lives on the column it filters. Click a heading to filter by it — click TOOL and type rapid7 to see only Rapid7's products, click CATEGORY and pick from the list, click LICENSE for open-source or commercial. Filters combine, and each shows as a chip you can click to remove.
• The arrows beside each heading sort by that column; click again to reverse. Newest release tells you when each tool last shipped, and Added when we first put it under watch — sort by Added to see the newest additions to the watchlist first (the same list the home page's "recently added" section links to).
• ACTIVITY sparklines each tool's commit volume over the last year, and POPULARITY shows its GitHub stars — sort by either to surface the most actively developed or most popular tools in the landscape.
• The API and MCP columns show a tool's programmable surfaces. A check means the tool offers that surface — click it to open the docs. A highlighted check means we track that surface and diff it over time — click it to open the tool's catalog page instead. A dim dot means we haven't found that surface for this tool.
• The ★ heading narrows the table to the tools you've saved.

Click any tool to open its card, which charts three streams of activity across its whole life — release notes, changelog entries, and code commits — alongside the derived signals described below.

Open the tool and follow the features link. Every other view answers "what changed" in reverse-chronological order; the Features page answers "what is this", as one list of the capabilities the tool offers.

• Every feature opens to show what it rests on. Click the + beside one and you get the evidence underneath it — the release notes that described it, the command-line flags and their help text, the API endpoints, and the output of runs we recorded. Nothing is listed as a feature unless something in the corpus evidences it.
• Lines in monospace are the tool's own words, parsed from its source or its API document. Everything else is our summary of a dated release, linked back to the vendor's own notes. The page keeps the two visibly apart so you always know whose sentence you are reading.
• Dates are when we first saw a capability, not when the vendor shipped it. We only see back as far as we have been watching a tool, so the page says "first seen" and never claims an origin date we cannot support.
• The list grows and does not reshuffle. A feature keeps its identity as new evidence lands, so one you read last month is still there this month — renamed if the tool renamed it, and marked retired, never deleted, if a release says the capability went away.
• Where a capability matches our shared vocabulary, it also carries a comparable label — the groundwork for asking which tools do a given thing.

A tool needs at least three evidenced features before it gets a page, so a tool we have only just started watching won't have one yet. Its absence is a statement about our coverage, not about the tool.

Yes. For tools that publish an OpenAPI/Swagger spec, we snapshot their HTTP API and diff it each day. When endpoints — or their parameters and request/response schemas — are added, removed, or changed, that appears as its own entry in the daily newsletter, independent of whether the tool shipped a release that day. Removed endpoints and newly-required parameters are flagged as breaking. Endpoints newly marked deprecated are called out separately — they still work, so they aren't breaking yet, but the flag is usually the only notice you get before one is removed. The first time we find a tool's spec at all, we say so — with a breakdown of what the API actually covers, one line per capability area, taken from the spec's own descriptions — so you learn both that a tool has an API and whether it does anything you need. Each tracked tool also has an API catalog page grouping its endpoints by capability area, with deprecated ones marked in place, its recent changes, and — when you open an endpoint — its parameters, request body, response shape, and the vendor's own example call. It's reachable from the "APIs" button in the tool's detail card on the Tools page. Plenty of vendors publish an API reference page but no machine-readable spec; for those we watch the reference page itself and report what was added, pulling out newly documented endpoints and any deprecation or sunset notice. Those entries are less precise — the page is prose, so we can quote it but can't always name the exact endpoint — and where a real spec exists we use that.

We give the same treatment to MCP (Model Context Protocol) servers — the surface tools expose for AI agents. Where a tool's repo carries an MCP server, we detect it, extract the tools it exposes, and diff that surface over time; when tools are added or removed, that appears as its own entry in the daily newsletter, independent of any release. Each tracked tool also has an MCP catalog page listing its current tools and recent changes, reachable from the "MCP" button in the tool's detail card on the Tools page.

Yes. Open-source projects announce what they ship in a release, but commercial vendors often don't — the release notes say "various improvements" and the actual launch lands as a press release in the vendor's newsroom. So we watch those newsrooms too, and a genuine product announcement appears as its own entry in the daily newsletter, tagged PRESS and linking to the announcement itself.

"Genuine" is doing real work there. A vendor newsroom is mostly not about the product, and everything that isn't gets dropped: funding rounds and valuations, executive hires and board appointments, analyst-report placements and awards, earnings, conferences and webinars, threat reports and surveys, customer-win announcements, rebrands. What's left — a new product, a substantial new capability, a beta reaching general availability, an acquisition that changes what the product does — is summarized the same way a release is, with the marketing language stripped out. An announcement that never says what actually changed doesn't get an entry. The first time we start watching a vendor's newsroom we read its archive silently, so a decade of old announcements never lands in one issue.

Yes, and it's often where the real detail is. Plenty of features are explained properly in an engineering blog post and get a single line in the changelog — or no line at all. So a vendor's blog is read as its own channel, and a post that announces or documents something the product now does appears in the daily newsletter tagged BLOG, linking to the post.

The filtering is the hard part, because a vendor blog is mostly not product news. Write-ups of vulnerabilities in other people's software, tutorials and how-tos, listicles, opinion pieces, threat reports, compliance explainers, conference recaps, customer stories and hiring posts are all dropped — on one real vendor blog that's 98% of everything published. The test applied to what's left is whether you could do something new with the product after reading it; explaining a capability that already existed doesn't count. As with newsrooms, the first time we start reading a blog we read its archive silently, so years of old posts never land in one issue.

Some AI tools ship continuously and cut no GitHub releases at all, so a feed that only watches releases sees nothing from them. For those we read the project's own commits and write the summary ourselves, and every such entry links to the exact range of commits it describes so you can check it. Where the project tagged a version, the entry is pinned to that tag. Where it did not, the entry is labelled "changes since" the date that window opens — not a version number, because the project never said it shipped anything and we won't say it did. Each window normally picks up where the last one we published ended, so one issue's commits aren't described again in the next. Two cases break that and we'd rather say so: the first window for a project has nothing to follow on from, and if a project rewrites its history the commit we were resuming from can disappear, in which case we fall back to a date range and that one window can overlap the previous one. A project that committed nothing in the window gets no entry at all.

Open-source AI tooling is not permanent — projects get abandoned, absorbed into something larger, renamed, or simply deleted along with the account that hosted them. When a tool we track goes away, we retire it and say so: a "no longer available" entry appears once in the daily newsletter, naming what happened, what we actually checked to establish it, and the successor project where there is one.

A retired tool stays listed rather than being deleted, so links and entries in previously published issues still resolve — it is simply no longer fetched or updated. We deliberately keep this separate from the case where a tool is alive and we merely cannot watch it (a feed goes behind a bot-check, a blog turns JavaScript-only). Calling a live project dead because our own plumbing broke would be a false statement about someone else's work, so those are never announced.

A map of the AI toolchain drawn by its people rather than its code. Two tools are linked when they share the maintainers who build them, and the clusters that fall out are real: the reverse-engineering family (Capstone sits underneath both Radare2 and Rizin), the ProjectDiscovery suite, the Kali web-testing tools. Radare2 and Rizin share 227 contributors — Rizin is a fork, and the bench never really split.

It answers a question no single project's contributor list can: which tools would wobble together if one person walked away. A shared maintainer is not a dependency — two tools can share a person without either relying on the other's code — so read it as a map of human connections, not of software ones.

It names no individuals, and publishes no email addresses. We use the email in a commit as an identity key — it's the most stable handle git gives us — and then discard it. The map shows tools, not people. We can see exactly which maintainers hold the ecosystem together, and we've chosen not to publish a ranked list of them: git authorship is public, but compiling thousands of maintainers across hundreds of repositories into a browsable index of load-bearing individuals is a different thing from any one project's contributor list, and not one those maintainers asked for. The fragility signal survives as a count.

• A link requires *at least 2 people with 5+ commits in both projects*. A drive-by typo fix doesn't make two tools related.
• Link weight counts distinct people, not commits — one prolific maintainer is one link, not a thousand.
• Bots are excluded (dependabot alone touches 150 of the repos we watch), as are unconfigured-git placeholder identities like "Your Name", which would otherwise merge dozens of unrelated people into one fictional maintainer.

One caveat worth knowing: a person who commits under several email addresses is counted as several people, so if anything the links are undercounted.

Seven things the raw data can tell you that a README won't, computed from the tool's full commit history, its release notes, and its documentation:

• Bus factor — how many people this project actually is. If one person wrote most of it, that's a supply-chain fact worth knowing before you build on it. (sudo: one maintainer, 98% of 15,000 commits.)
• Top contributor org — who funds the work, inferred from the email domains in the commit history. See the caveat below.
• Cadence — whether the code and the releases are moving together. Building means commits are up but releases have paused: something is coming. Coasting means releases still trickle out while the code has gone quiet — often the last thing that happens before a project stops.
• Breaking releases — what share of this tool's releases contained a breaking change. The practical question: how often does upgrading this thing cost me an afternoon?
• Docs lead time — whether the documentation changes before a release ships or catches up afterwards. Writing first is the mark of a mature product org.
• Contributors — whether the contributor base is growing or shrinking. People leave before the commits stop, and the commits stop before the releases do.
• Work mix — new capability versus firefighting, from commit subjects.

Every signal shows the evidence it rests on, because a bus factor drawn from three commits is not the same claim as one drawn from three thousand. Where the evidence is too thin to support a number, we show nothing rather than guess.

We look at the email domains in the commit history: work done from an @sysdig.com address is work Sysdig paid for. But most open-source developers commit from a personal address even when they're employed to do the work — so a large share of any project's history simply cannot be attributed to anyone. That's why the card reports the org's share of the commits we could attribute, and tells you what fraction of the history that was.

Read it accordingly. "Sysdig, 86% of attributable commits — 12% of history is attributable" means: of the small slice we can trace to an employer, Sysdig dominates. It does not mean the other 88% is independent volunteers. We also ignore domains with only one author behind them — a lone maintainer's own domain is a vanity address, not a company.

All the way. The commit line is the repository's entire history — for Falco that's every month since 2016, for some tools back to the 1990s. We read it from the git history itself rather than from an API that only reports a rolling year, so a quiet month inside the span is a real quiet month, not missing data.

The release-notes and changelog lines run the full span too. Commercial products with no repository we watch have no commit line at all.

They describe how recently a tool's repository was last pushed to — any commit, on any branch, not just a tagged release: active within the last 30 days, maintained within 90, and stale beyond that. For a tool with no repository we watch (most commercial products), the date of its last tracked release stands in. Tools with neither signal show as unknown. It's a rough liveness cue for the watchlist, not a quality judgment — some excellent, finished tools sit still for a year.

Star the tools you actually run and the site adapts to them. The ★ filter narrows any newsletter issue and the Tools page down to just your tools, and the my toolchain panel (the chip in the corner, on every page) lists them together and lets you pin the version you're running to get an upgrade digest. It also shows what has shipped for your tools — the last 30 days' worth until you dismiss it, and everything since your last visit after that. Expand it to read the releases themselves; you can only dismiss the list once you've opened it.

There is no account and no login. Your starred tools and version pins live in your browser's local storage and are never sent to a server — which also means they're per-browser, and clearing your site data clears them. Use the "copy link to my toolchain" button if you want to carry the set to another browser or share it, or export an OPML file to subscribe to your tools in a feed reader.

Every entry on the site is written as news, addressed to a reader who is already on the latest version. Almost nobody is. So in the my toolchain panel you can pin the version of a tool you actually run, and the site rolls up every release since then into one answer: what you'd gain, what would break, and which commands changed. It also appears on the tool's own page once you've pinned it.

A digest only covers releases we have an entry for, and it always says so — "covers 0.38 → 0.44 (7 releases)". If you're further back than our archive goes, pick older / not listed and it will tell you where our coverage starts rather than pretend to be complete.

Same way we write everything else: from the vendor's own release notes. A breaking change is something that will break a working setup when you upgrade — a renamed or removed flag, field, API, or config key; a changed default; a dropped platform; a required migration. They're kept separate from the feature bullets, because they answer the opposite question.

An LLM extracts them and a second pass verifies each one against the source material, rejecting anything the notes don't actually say — a false breaking change is worse than a missing one, since it would scare you off an upgrade you should have taken. They're only as good as the notes, though: if a vendor ships a breaking change and doesn't write it down, we can't surface it. Never treat a digest as a substitute for the vendor's own upgrade guide.

Two ways, depending on how much you need. For following releases, the site publishes machine-readable feeds — no key, no account, free:

• The Feeds page is the front door to all of this — RSS and OPML, newsletter / category / per-tool, each with a copyable URL.
• /rss.xml — every release issue (Tail + Head), RSS 2.0.
• /newsletter/releases.xml, /newsletter/highlights.xml, /newsletter/docs.xml — each newsletter series as its own RSS feed.
• /feeds/category/<category>.xml — one aggregate feed per tool category (the newest release of every tool in it), plus a .opml bundle at the same path to subscribe to each tool in the category individually.
• /tools/<tool>/rss.xml — one feed per tool, an item per release. Follow only the tools you run instead of the whole firehose. The my toolchain panel will export an OPML file of your starred tools' feeds, and /feeds/all-tools.opml bundles every watched tool's feed — either imports into any feed reader in one go.
• /tools.json — every tool that has shipped a tracked release, with its newest one.
• /entries.json — every entry from every issue, flattened.
• /toolchain-catalog.json — the full watchlist, the catalog behind "my toolchain".
• /search-index.json — what ⌘K searches: every tool and issue.
• /stack-index.json — the lookup behind paste-to-detect-your-stack.
• /llms.txt — a summary of the site for LLMs.

For querying instead of following — filtering releases across the whole watchlist, pulling a tool's SBOM or captured CLI examples directly, reading analytics as data — there's an authenticated API for Researcher and Business subscribers. Generate a key from your account page.

Press ⌘K (or Ctrl-K) anywhere on the site to jump straight to any tool or any issue.

Analytics charts the release data the newsletter is built from, so you can see the market rather than the day: which tools ship fastest, which tools write the best (and worst) release notes, which categories are most active, what themes recur in release notes over time, how healthy each category looks, which categories are speeding up or slowing down, which tools have gone quiet against their own release rhythm, how long tools stay in active development by category and open-source versus commercial, how each tool's programmable surfaces (APIs and MCP servers) evolve over time — which endpoints and agent tools are added or removed — and which commercial SaaS platforms (and their specific products) have the most service disruptions on their own status pages. Each chart carries an "about this data" note explaining its provenance and caveats. While the site is in alpha, each chart also carries a confidence grade — solid (measures what it says), incomplete (missing or out of date, still being filled in) or don't trust yet (known to misread today) — and anything graded below solid says underneath it exactly what to distrust.

The page also carries a defect analysis drawn from every release note we have collected: which kinds of failure each tool keeps shipping fixes for, how concentrated those fixes are, which tools break in the most different ways, whether repair work is crowding out new features, and whose fixes do not hold. Every chart on the page is readable without an account — some of them mask the tool and category names, which is the next question.

A handful of charts rank named tools, platforms and categories against each other — worst release notes, most platform downtime, most repeated defects, whose fixes reopen. On those, the shape and every number are shown to everyone and the names are masked; Researcher and Business subscribers see the labels. It is the one place the site asks for something back, and it applies to the ranking charts only — the tools directory, every issue, and the numbers behind these charts are open to everyone.

Nothing is hidden about how the numbers are reached: the methodology publishes every rubric and threshold, each chart carries its own "about this data" note, and both are enough to re-derive a score by hand. What a plan buys is who is on which end of it.

For the commercial tools that run as SaaS platforms, we read the vendor's own public status page (the standard Statuspage.io incident history) and track how often each platform — and each of its individual products — is degraded or down. The chart ranks the last 90 days by downtime (the wall-clock time any part was impaired), by number of incidents, or by uptime %; bars are colored by the worst severity seen. Overlapping incidents are counted once (real wall-clock time, not double-counted across affected products), and only genuine degradations count — informational and scheduled-maintenance notices are excluded.

It is entirely self-reported by each vendor: a disruption a vendor never posts is invisible here, and vendors differ in how granularly they log incidents, so treat this as a comparison of what each platform discloses, not an independent audit. One status page counts as one platform — where a vendor sells several products behind a single status page, those products appear as its components. Only the most recent incidents each vendor publishes are available, so a very active platform may under-count older incidents in a long window.

No. It flags a project that had a steady release rhythm and stopped, measured against its own cadence rather than a fixed date — so a tool that has always shipped once a year isn't mistaken for silence, while one that shipped every fortnight for years and has been still for months is. That's a different question from the "stale" label on the tools page, which only asks how long it has been, not whether that's unusual for that tool.

It is not a judgement about a project or its maintainers. A finished tool legitimately stops shipping — nothing is wrong with it, and it will still appear here. A repo can also be actively developed without cutting releases. That's why every row shows the tool's usual rhythm and the size of the gap side by side: so you can see the reasoning and dismiss it. Read it as a prompt to go look at the repo, never as a verdict.

Every release note we collect is scored 0-100 by a fixed rubric: depth (how much the note actually explains — length, sections, bullets that describe a change rather than restate a commit subject, links to issues and docs), usage examples (code blocks, commands, config snippets a reader can run), and transparency (breaking-change and upgrade notes, AI advisories, deprecations). A tool is scored on its median note out of its most recent 10 from the last 24 months — a typical note, so one great release can't carry it and one dud can't sink it. Tools with fewer than 3 notes in that window aren't ranked. Because the score is a real note's score, the three parts always add up to the total you see on the bar. Each tool is judged on the best channel it publishes in — the release itself, a CHANGELOG file in its repo, or a curated changelog / release-notes page. A tool that ships empty GitHub release bodies but documents every release on its own docs site is scored on those notes rather than on the blank release feed. A tool only scores zero when we find no notes for it in any channel we track — if a project documents releases somewhere we're not looking, that's a gap in our sources and we want to hear about it. The score judges the notes, not the software: a superb tool with thin notes will rank badly, which is exactly what the chart is for.

Articles is the long-form side of the project — field notes on AI tooling, product craft, and the work behind building and buying AI products. They're separate from the newsletter: the newsletter tracks what shipped this week, an article works one subject through end to end. Nothing is published there yet; the first pieces are being written.

• The newest piece is featured at the top; the rest run as an archive grid you can narrow by topic with the chips above it.
• Longer pieces carry a contents rail on wide screens and a reading-progress bar at the top of the window, so you can see where you are in a piece.
• Everything is free and there's no paywall or signup. Each article also links back to its original post on Substack.

Articles are searchable from the command palette (⌘K / Ctrl-K) by title, topic, or what they're about — not just the exact headline.

From the tools themselves. Around 800 sources across 46 categories are monitored continuously: GitHub and GitLab release feeds for open-source projects, and vendor changelogs and documentation pages for commercial products. Everything published is derived from what the vendor or maintainer actually wrote — release notes, changelogs, docs — not from press coverage or rumor.

Yes, and it's worth being precise about which parts. We use a mix of frontier and open-weight LLMs, picked per task:

• An LLM writes the summaries. Every entry — the headline, the feature bullets, the usage examples — is written from the vendor's own release notes and documentation.
• An LLM picks the weekly highlights, comparing the week's releases against each other.
• An LLM groups a tool's feature list. Every tool page links to a Features page listing what that tool does. The model does one job there: it groups evidence we already hold into capabilities and names each one. It never writes the evidence — every line you can expand under a feature is a release note we published, a flag's help text parsed from the tool's own source, an endpoint from its API document, or the output of a run we recorded. A proposed feature with no evidence behind it is discarded rather than published.
• An LLM explains the captured runs. On a tool page, the "Explain it" panel under a recorded command is written from that run's own output and the fixture answer key — what it was pointed at, and what came back. Every figure in it is checked against the recording, and an explanation that mentions a number the run never printed is thrown away rather than published. The command and the output above it are the recording itself, untouched.
• An LLM explains the technology an entry names. Where a summary mentions something a tool is built on — AF_XDP, AWS ENA, OTLP — the term carries a dotted underline, and hovering or tapping it gives you a sentence or two on what it is. Each term is explained once and reused everywhere it appears, the tool's own features are never treated as terms, and a definition we are not confident in is dropped rather than shown. Some of them are written by hand.
• Humans decide what gets watched. The source list, the categories, and the documentation pages tracked are all curated by hand.
• No human approves each issue before it publishes. The daily pipeline runs, builds, and deploys on its own — Jon reviews the data regularly, but after the fact. See How do you keep the data accurate? below.

The summarizer is constrained against inventing things: a flag, setting, or API can only appear in an example if it appears verbatim in the source material, and an entry that fails to summarize cleanly is dropped rather than shipped. It is still a language model, so errors are possible — if you spot one, email me and it'll get fixed.

This is only useful if you can trust it, so accuracy is engineered rather than hoped for. Five rules the pipeline actually enforces:

• Primary sources only. Everything published is derived from what the vendor or maintainer wrote themselves — release notes, changelogs, docs, press releases — never from press coverage, rumor, or another newsletter.
• Nothing is invented. A flag, setting, or API can only appear in an example if it appears verbatim in the source material, and an entry that can't be summarized cleanly is dropped rather than shipped. Breaking changes get a second pass that re-checks each one against the source and rejects anything the notes don't actually say — a false breaking change is worse than a missing one, since it would scare you off an upgrade you should have taken.
• Every figure in a run explanation is checked against the recording. On a tool page, an explanation that mentions a number the command never printed is thrown away rather than published. The command and its output are the recording itself, untouched.
• "Not checked" never renders as "nothing found". A tool that hasn't been analyzed for something looks different from one analyzed and found clean. We don't manufacture all-clears — silence means we don't know, and the page says so.
• The source list is a gate. A miscategorized or malformed source stops the whole run instead of quietly publishing wrong data, and every item is keyed so the same release can't reappear as if it were new.
• A human reads it. Jon reviews the data regularly once it's live — spot-checking entries against the vendor's own notes, correcting anything he finds, and tightening the pipeline when a class of error shows up rather than patching the single entry.

What that does not buy you: we can only be as good as what vendors write down. If a project ships a breaking change and doesn't document it, we can't surface it, and a vague "various improvements" stays vague. The human review is regular, but it happens after publication — no one signs off on each issue before it goes out — and a language model is doing the writing, so errors are possible. The raw source material behind every entry is archived, so any claim can be traced back to the text it came from — if something looks wrong, email me and it'll get fixed. Never treat a digest as a substitute for the vendor's own upgrade guide.

Because they're filtered out on purpose. Bug fixes, crash and regression patches, dependency bumps, CI and refactor noise, and CVE-only releases are all excluded — including routine CVE work: a scanner adding detection for a specific CVE, or a tool patching a CVE in its own code, is a rule-set or AI update, not a new capability. (A CVE mentioned as part of a genuinely new feature still shows.) A release that contains nothing but fixes doesn't get an entry at all. The newsletter answers "what can this tool do now that it couldn't before?", and a fix, however welcome, isn't a new capability.

Ask. Send the tool by email — open-source or commercial, both are welcome. It helps to include the repo or the changelog page and where the product documentation lives, since those are what get monitored.