Treg: a metered proxy and registry for agent tool calls

The subscription wall treg is built to route around

The README states the problem in concrete terms: the tools an agent needs for real work sit behind subscriptions nobody buys for a single run. It names Semrush at $139/mo, Moz at $99/mo, Crunchbase at $99/mo and Apollo at $59/seat, and adds two categories that are harder to solve than price: signup walls, and services with no public API at all because access is invite-only, partner-only or gated behind app review. Treg's answer is to hold those accounts itself and bill fractions of a cent per call against a team prepaid balance. The README claims 3,000+ catalogued endpoints across 60+ providers, grouped by capability: keyword and rank tracking, backlinks and authority, AI visibility, trending and discovery, publishing to socials, people and company enrichment, ads management and measurement. The intended user is an agent that needs to complete a task once, not a team that has already standardised on a vendor. The secondary user is a team that already holds credentials and wants every teammate's agent to reach them. Those are different products sharing one proxy, and the README is explicit that the second one is never metered.

Relay, never model: what the proxy actually does

The README states one rule for the proxy: it relays, never models, the upstream, and injects auth server-side. That single sentence explains most of the architecture. Treg does not normalise response shapes across providers, so a caller still has to read each endpoint's example response from `treg catalog get`. What it does normalise is authentication and billing. The unit of registration is a tool, and a tool comes in two forms. An endpoint is an upstream `base_url` plus credential bindings, where each binding injects one secret into the request and a single request can carry several, for example an OAuth bearer and a `developer-token` header together. A CLI is a vendor binary such as `stripe`, `gh` or `vercel` run with the credential injected. A skill or bundle packages a `SKILL.md` recipe with its secrets and its tools and registers them as one unit. Catalogued calls resolve through a credential ladder: a team-registered tool for that provider wins first, then a stored team secret injected through a virtual tool, and only if neither exists does treg's own key serve the call, billed to the team balance. The stated consequence is that connecting a key you already pay for makes those calls free of the balance rather than duplicating them.

Getting from install to a first billed call

The README gives a four-step quickstart. `curl -fsSL https://treg.to/install.sh | sh` installs the CLI and points it at the registry. `treg login` signs in, with GitHub as the default, `--email` for a one-time code, and `--token` for agents and CI. Then `treg catalog search "backlinks for a domain"` finds a tool by what it does, `treg call tikhub.tiktok.user.profile --query uniqueId=tiktok` performs a call with no key registered, and `treg balance` reports exactly what that cost. The token travels as an `X-Treg-Token` header and is the same for every tool, which is the whole point of the OpenRouter comparison. Team discovery uses `treg tool ls`, credential health uses `treg health`, and `treg onboard` runs a guided walkthrough. There are three additional entry points. As a Claude Code plugin, `/plugin marketplace add superdesigndev/treg` followed by `/plugin install treg@treg` installs with no token, and the skill loads as `treg:treg` and walks the agent through the CLI, sign-in and `treg mcp install`. For other agents, `npx skills add superdesigndev/treg -s treg` installs the skill; the README notes the `-s` flag matters because without it you also get the repository's internal dev skills. There is also a Claude.ai connector at `https://treg.to/mcp/v2/`, separate from the `/mcp/` surface, which exposes only curated catalog endpoints and separates read calls from write calls so the client receives accurate safety signals.

The pricing rules that decide whether a call happens at all

Two behaviours in the README are worth reading twice. First, an endpoint treg has no published price for is refused, not served free, and the caller is told to connect their own key instead. That is a defensible cost control, but it means catalog coverage and billable coverage are not the same number, and the 3,000+ figure does not tell you how many endpoints are actually callable on treg's keys. Second, where several providers serve one capability, `treg catalog search` lists them side by side with prices and the choice is the caller's. Treg does not silently pick or fail over between providers. The one exception is opt-in: `treg.<capability>` routed endpoints, where treg selects the provider and names it. There is a further disclosure rule. When treg's own account for a provider is exhausted, it may serve the same endpoint through a treg-owned relay account, and this is disclosed on the response; a team can opt out. Out of balance is an HTTP 402 carrying `balance_micro`, `estimated_cost_micro` and a `topup_url`, which is the right shape for an agent to act on without parsing prose. New verified accounts get $1.00 free on an eligible team, once. `treg topup` adds funds or configures automatic top-ups.

Where treg is the wrong tool

The relay-never-model rule has a cost. Because responses are passed through rather than normalised, an agent that switches providers for the same capability still needs provider-specific parsing, so the abstraction saves you credentials and billing, not integration work. The per-call model also cuts against heavy, predictable usage: a team running thousands of enrichment calls a day will find that the monthly subscription treg exists to avoid was the cheaper instrument, and the prepaid balance turns a fixed cost into a variable one that has to be monitored. The refusal rule is a second boundary. If the endpoint you need has no published price, treg will not serve it on its own key, so the catalog's breadth is not a guarantee of access. A third limitation is structural rather than stated: the README describes a hosted service at treg.to on Render, with self-hosting mentioned in one line and no deployment documentation in the supplied material. Anyone whose threat model forbids sending upstream credentials through a third-party proxy is outside the design, not merely unserved by it. Finally, the repository licence is reported as NOASSERTION, which means the licence could not be determined from the repository metadata. That is not a statement about what the licence is; it is a statement that you cannot assume one.

How this differs from wiring an MCP server per provider

The obvious alternative is the one most teams already run: install an MCP server per provider, one per credential, and let the agent pick from the resulting tool list. The difference is where the credential lives and who pays. In the per-server model, each provider's key is configured into each agent environment, the tool list grows with every provider, and there is no shared meter, so cost attribution across a team is guesswork. Treg centralises both: one token, one base URL, credentials injected server-side so callers never hold keys, and a balance that reports what a call cost. The trade is that you now depend on a proxy for availability, and you inherit its pricing rules, including the refusal for unpriced endpoints and the opt-out for relay accounts. A second alternative is a general secret manager or a self-built credential broker. That solves key custody but not discovery: it gives you no `treg catalog search` equivalent, so the agent still has to know which vendor sells backlink data before it can ask for it. Treg's stated premise is that you ask for the task, not the tool, and that premise only holds if the catalog is the discovery surface.

Maintenance, self-hosting and the licence question

The material here is thin, and that is itself the finding. The README says the registry is built for the Superdesign team, live at treg.to, and that anyone can self-host, but it supplies no deployment instructions, no environment variable list and no migration or upgrade path in the supplied text. The CLI installs from a shell script hosted at treg.to, so a self-hosted deployment implies pointing that script or the CLI at your own base URL, though the supplied material does not document how. Upgrade cost therefore splits by mode. On the hosted service, upgrades are the operator's problem and the cost is the balance and any provider price changes. On a self-hosted deployment, you own the proxy, the credential store and the catalog data, and you own keeping the endpoint definitions current as upstream APIs change, which is precisely the maintenance the README says the relay design is meant to avoid for callers. The repository is reported as not archived, with a last push of 2026-09-10, and no releases were retrieved, so there is no versioned release channel to pin against in the supplied material. On licensing, the metadata reports NOASSERTION, meaning the licence could not be determined. Treat that as an open question to resolve from the repository itself before any self-hosted or commercial use, and take your own advice on it rather than mine.

Editorial conclusion

Adopt treg if your agents need occasional access to enrichment, scraping or social endpoints you do not want to buy monthly subscriptions for, and if a prepaid balance with per-call metering fits your accounting. Do not adopt it if you need guaranteed provider-level SLAs, if you cannot accept a third party holding upstream credentials, or if your work depends on endpoints treg has no published price for, because those are refused rather than served. Before committing, verify three things against the live service: which endpoints your team actually needs appear in `treg catalog search` with a price, what `treg balance` reports after a single `treg call`, and whether the NOASSERTION licence on the repository permits the self-hosted deployment you have in mind.

Official sources

1. Issues
2. Project website
3. README
4. superdesigndev/treg on GitHub