How AI agents monitor open-source releases
An AI agent checks for new open-source versions by calling a wire that reads GitHub release feeds at runtime. It returns release tags for nine major runtimes and frameworks, filtered by project and time window, each with the version string, publication date and a link to the release notes.
/mcp. Nothing here needs an API key or a signup.
A coding agent carries a frozen picture of every library it writes against. That picture ages badly and it ages silently: the agent does not know that the API it is recommending was deprecated four versions ago, and nothing in its own reasoning can tell it.
The nine projects, and the boundary that matters most
| Filter value | Project |
|---|---|
node | Node.js |
python | CPython |
kubernetes | Kubernetes |
rust | Rust |
go | Go |
react | React |
pytorch | PyTorch |
deno | Deno |
bun | Bun |
Read that list as the whole promise, because it is. This wire does not read your package.json, your lockfile or your repository. It reads nine GitHub release feeds. If your dependency is not one of those nine, the wire returns nothing for it, and an empty result means "not on this wire", never "you are up to date".
Actual dependency monitoring across a full tree is a different job with good tools already built for it: Dependabot, Renovate and npm outdated all read your manifest and none of them cost half a cent a call. Reach for those when the question is "what in my project is behind".
Reach for this wire when the question is the one an agent actually has at runtime: did the runtime I am writing against ship something since my training data ended. That question needs one call and no repository access, which is exactly the shape an agent can handle mid-conversation.
The call an agent makes
# free preview, top 3 results, no payment and no wallet curl "https://thebotwire.com/releases/preview?project=node" # paid, $0.005: everything tagged across all nine in the last 14 days curl "https://thebotwire.com/releases/latest?since=14d&limit=20" # one project, longer window curl "https://thebotwire.com/releases/latest?project=kubernetes&since=30d"
Parameters are project (the nine values above), q (version string or release title text), since (24h, 3d, 14d, 30d) and limit (1 to 50). Because a given project can go weeks between tags, this wire keeps a 30-day window and defaults to a 14-day lookback rather than 24 hours. The route costs $0.005 per call in USDC on Base, with no API key.
Release cadence is why the window is 30 days
Major projects ship on a calendar, and the calendar is slow. The Node.js Release Working Group publishes its schedule openly: a new semver-major is branched every six months, even-numbered versions in April and odd-numbered in October, and each even release then gets 12 months of Active LTS followed by 18 months of maintenance.
A 24-hour query against that rhythm returns empty almost every day of the year. Thirty days of history means a single call gives an agent the current state of a project rather than a coin flip on whether it happened to poll during a release week.
Patch releases land more often than majors, which is where the real signal usually is. Security patches in particular tend to arrive as an out-of-band point release, and the advisory that explains them travels on a different wire entirely, covered in how agents monitor CVEs and security advisories. When a release lands during an incident, provider status is on the cloud outage wire, and the routing table lists which endpoint owns which question.
Prereleases are in the feed, and they are not releases
GitHub release feeds carry what maintainers tag, and maintainers tag release candidates, betas and nightlies alongside stable versions. An agent that reads v25.0.0-rc.1 and tells a user "Node 25 is out" has said something false about software nobody should deploy yet.
Two rules handle it cleanly:
- Read the version string before reporting it. Anything with
rc,beta,
alpha or -next in the tag is a prerelease. Say so, or filter it out.
- Link the release notes. The tag alone does not say whether a version is a
security patch, a feature drop or a breaking change, and those three deserve three different responses from an agent.
FAQ
Can this wire tell an agent if its project dependencies are out of date?
No, and this is the boundary worth stating plainly. The wire reads nine GitHub release feeds and has no access to your manifest, lockfile or repository. For a full dependency audit use Dependabot, Renovate or the package manager's own outdated command. This wire answers whether a major runtime shipped a version.
Why is the default lookback 14 days here and 24 hours on other wires?
Because releases are sparse. Kubernetes ships a minor roughly three times a year and Node cuts a major every six months, so a one-day window would return empty on almost every call. Fourteen days of default lookback inside a 30-day window gives a useful answer on any day it runs.
How would an agent watch one project cheaply?
Pass it to project and call once a day. A daily check on a single project is about 30 calls a month, or roughly $0.15 at $0.005 a call. Watching all nine costs the same, because one call with no project filter returns them together.
Does the agent need a GitHub token?
No, and no account of any kind. The route answers HTTP 402 with a price offer, an x402 client signs a USDC authorization on Base and retries, and the releases come back. Wallet requirements are listed in what an agent wallet needs on Base.
Sources
Release data on this wire comes from the public GitHub release feeds of the nine projects listed above. The Node.js cadence quoted here is published by the Node.js Release Working Group at nodejs/Release, which documents semver-major branches every six months, April for even and October for odd releases, and 12 months of Active LTS followed by 18 months of maintenance. Poll cadence and wire count for this service are live at thebotwire.com/health.
Related: How do AI agents monitor CVEs and security advisories? · How do AI agents check whether AWS or OpenAI is down?