Change feed for AI agents
The only change feed that types every change and attaches its official proof
For AI agents that already have a budget and are authorized to buy, run by developers and small teams who operate them in production on model, search, extraction and browser APIs.

Your agent runs on services it does not control: a model API, a search API, an extraction API, a browser API. When one of them changes a price, a limit or an endpoint, the agent usually learns it from a failed call.
Vary reads one shared catalog of at most five providers, once a day, with code. Each change becomes a typed event, and each event carries the official page it came from.
Two things stay out of the way. An announcement is never filed as a fact, and what Vary cannot establish is marked unknown instead of guessed.
Your agent asks for those events over REST, or through a light MCP endpoint, and decides for itself what to do next.
What an agent gets for its money:
- One shared catalog of at most five providers, the same catalog for every buyer.
- A daily check, done by code, that turns each change into a typed event with its official proof attached.
- Two ways in: a REST API, and a light MCP endpoint your agent can call as a tool.

The catalog
Five providers, checked once a day by code. Freshness is stated before data: each source carries the time of its last successful check.
| Provider | Service | Sources checked daily | Last successful check (UTC) |
|---|---|---|---|
| Checking status | |||
Live from GET /v1/catalog. Expansion happens only when usage and margin justify it.

A feed is only useful if an agent can trust what each line is. Vary sorts every entry into one of three kinds and never lets them blur.
Fact
A change confirmed by an official source, with that proof attached to the event.
Announcement
Something a provider says is coming. It is kept apart from facts.
Unknown
What Vary cannot establish. It stays unknown and is never filled in with a guess.
Because the kind is part of every event, an agent can filter on it before it acts.
A sample of the feed
Sample ยท real events from the daily check
GET /v1/sample
Checking the feed
Next event waits for the next daily check
| Way in | Call |
|---|---|
| REST | GET /v1/sample |
| MCP endpoint | get_sample() |
Free calls, no key. This endpoint serves the real feed.
One price, one experiment
Vary is a hypothesis, not a product line: that an agent with its own budget will pay a small amount to stop finding out about API changes the hard way. So there is one offer, and the terms are short.
9 USDC
the whole price
One experimental offer, stated as a hypothesis to test. There is no other plan.
30 days
of access
To the shared catalog of at most five providers.
1,000
requests
Over REST or the MCP endpoint, within the 30 days.
90 days
of history, at most
Only as far back as the history actually available. Where there is less, you get less.

How it works

The loop is three steps long, and nobody has to watch it.
1
A daily sweep
Once a day, code reads the shared catalog of providers and looks for what changed.
2
Typed, with proof
Each change becomes an event with a type and its official proof. Unknowns stay unknown.
3
Your agent asks
It queries the events over REST or the MCP endpoint, and filters on kind before it acts.
Because the catalog is shared, every buyer reads the same events.

Unknown stays unknown.
Vary is a single bet. The only buyers it is built for are agents that already have a budget and the right to spend it, and the only thing it sells is the feed: typed events, each with its official proof.
9 USDC buys 30 days of access to the shared catalog, 1,000 requests, and up to 90 days of the history that exists.
See a sample
Limits
The catalog holds at most five providers, and it is shared. It is not built per customer.
The check runs once a day, with code. A change shows up after the next check, not before.
History reaches back only as far as it exists, up to 90 days.
Where Vary cannot establish something, the event says unknown. It is never filled in.
The offer is one experiment at one price: 9 USDC for 30 days and 1,000 requests.