Agents need dozens of APIs for real work. Semrush costs $139/month, Crunchbase $99, Apollo $59 per seat. Most teams do not buy those subscriptions for a single agent call. Treg (4,779 stars, trending #8 on GitHub Python) solves this by acting as OpenRouter for tools: one base URL, one token, thousands of endpoints priced per call from a cent.
The architecture is a relay proxy with server-side credential injection. You point an agent at treg.to, it searches the catalog for "backlink data" or "company enrichment," reads the price, and calls. The proxy injects the upstream API key, OAuth token, or CLI credential without modeling the provider's schema. Your agent never holds the secret. If your team owns a key for the same provider, that key wins and the call is never metered.
The Two-Tool Model
Treg splits tools into catalog and team-owned.
Catalog tools are endpoints Treg serves with its own key or through a verified public route. The proxy holds the provider account. You pay per call from a prepaid balance. New verified accounts get $1.00 free credit once. No provider signup required.
Team-owned tools are anything a teammate registered: a paid API account, an OAuth connection, a vendor CLI binary (stripe, gh, vercel), or a SKILL.md recipe. Own-key calls always win over catalog keys and are never metered. The proxy injects the credential at runtime but does not bill for the call.
This split solves the cold-start problem. An agent can call Semrush without a Semrush account. If your team later buys a Semrush subscription, you register the key once and every teammate's agent uses it automatically.
Credential Injection Without Modeling
The proxy relays requests without modeling the upstream API. It does not parse query parameters, body schemas, or response shapes. It only knows where to inject the credential.
Each endpoint has one or more bindings. A binding is a rule that says "inject this secret into this part of the request." Examples:
- Bearer token in
Authorizationheader - API key in
X-API-Keyheader - Developer token in
developer-tokenheader - Query parameter
api_key
A single request can carry multiple bindings. An endpoint that needs both OAuth and a developer token gets both injected server-side. The caller sends a generic request to Treg. The proxy looks up the bindings, fetches the secrets from its vault, injects them, and forwards the request upstream.
This design survives upstream API changes. If a provider renames a parameter or adds a new auth header, you update the binding. The agent code does not change.
CLI Execution with Credential Injection
CLI tools like stripe, gh, and vercel are first-class citizens. The proxy does not wrap them in a REST API. It runs the vendor binary directly and injects the credential at runtime.
When an agent calls a CLI tool, Treg:
- Looks up the registered CLI and its credential binding
- Fetches the secret from the vault
- Spawns the vendor binary with the credential injected as an environment variable or config file
- Captures stdout and stderr
- Returns the output to the agent
The vendor binary runs unmodified. This avoids the maintenance burden of wrapping every CLI in a custom API. It also means the agent gets the exact output the CLI produces, including error messages and formatting.
The credential never leaves the server. The agent sends a request like POST /cli/stripe/customers/list. The proxy runs stripe customers list with the team's Stripe key and returns the JSON.
Metering and Billing Boundaries
The metering boundary is simple: catalog calls use the prepaid balance, own-key calls do not.
When an agent calls an endpoint, the proxy checks if the team has a registered key for that provider. If yes, it uses the team's key and does not meter. If no, it uses the catalog key and deducts the call price from the team's balance.
The price is set per endpoint, not per provider. A Semrush backlink call might cost $0.05, a Crunchbase company lookup $0.02, a scraping call $0.01. The catalog lists the price before the call. The agent can decide whether to proceed.
The $1.00 free credit is a one-time grant when a verified account creates an eligible team. This prevents abuse while allowing anonymous verified calls. The credit is not renewable. Once spent, the team must add funds.
Endpoint Binding Model
An endpoint is a base_url plus one or more bindings. A binding specifies:
- Secret name: the key in the vault
- Injection target: where to put the secret (header, query param, body field, env var)
- Injection format: raw string, bearer token, basic auth, custom template
Example binding for a provider that needs both OAuth and a developer token:
{
"endpoint_id": "semrush_backlinks",
"base_url": "https://api.semrush.com/analytics/v1",
"bindings": [
{
"secret_name": "semrush_oauth_token",
"target": "header",
"header_name": "Authorization",
"format": "Bearer {secret}"
},
{
"secret_name": "semrush_developer_token",
"target": "header",
"header_name": "developer-token",
"format": "{secret}"
}
]
}
When an agent calls this endpoint, the proxy fetches both secrets, injects them into the headers, and forwards the request. The agent only sees the Treg URL and token.
State Management and Observability
Treg does not manage agent state. It is a stateless proxy. Each call is independent. The agent is responsible for maintaining conversation context, tool call history, and retry logic.
Observability is per-call. The proxy logs:
- Request timestamp
- Endpoint ID
- Team ID
- Upstream response time
- Upstream status code
- Metered cost (if catalog call)
- Error details (if failed)
These logs feed a dashboard that shows per-team usage, per-endpoint latency, and per-provider error rates. The dashboard does not expose upstream API responses. It only shows metadata.
The proxy does not retry failed calls. If the upstream returns 500, the agent gets 500. If the upstream times out, the agent gets a timeout. Retry logic belongs in the agent orchestration layer, not the proxy.
Security Boundaries
The proxy enforces three boundaries:
- Credential isolation: secrets are scoped to teams. A team cannot access another team's keys.
- Catalog key protection: catalog keys are never exposed to callers. The proxy injects them server-side.
- Rate limiting: per-team and per-endpoint rate limits prevent abuse.
The vault is a separate service. The proxy requests secrets on demand and does not cache them in memory. Secrets are encrypted at rest and in transit.
The proxy does not validate upstream API responses. It relays them as-is. This means a malicious upstream could return arbitrary data. The agent must validate responses before acting on them.
Deployment Shape
Treg is self-hostable. The reference deployment is a Python service with:
- FastAPI for the HTTP layer
- PostgreSQL for endpoint metadata and team state
- Redis for rate limiting
- A vault service (HashiCorp Vault or AWS Secrets Manager)
The proxy is stateless and horizontally scalable. Each instance can serve any request. The vault is the only stateful component.
The catalog is a JSON file or database table. Each entry is an endpoint with bindings, pricing, and metadata. The catalog can be updated without restarting the proxy.
The live instance at treg.to runs on AWS with:
- ALB for ingress
- ECS Fargate for the proxy
- RDS PostgreSQL for metadata
- ElastiCache Redis for rate limiting
- Secrets Manager for the vault
Likely Failure Modes
| Failure | Impact | Mitigation |
|---|---|---|
| Upstream API change | Binding injects credential into wrong field, call fails | Monitor upstream error rates, update bindings, notify teams |
| Vault unavailable | Proxy cannot fetch secrets, all calls fail | Vault HA, fallback to cached secrets with short TTL |
| Catalog key rate limit | Catalog calls fail, own-key calls unaffected | Per-endpoint rate limits, fallback to own-key if available |
| Prepaid balance exhausted | Catalog calls fail, own-key calls unaffected | Balance alerts, auto-reload option |
| CLI binary missing | CLI calls fail | Pre-install CLIs in container image, version pinning |
| Malicious upstream response | Agent acts on bad data | Agent must validate responses, proxy does not inspect payloads |
The biggest operational risk is upstream API changes. The proxy does not model the upstream, so it cannot detect schema changes. If a provider renames a required parameter, calls fail until the binding is updated. The mitigation is monitoring and fast binding updates.
The second risk is vault availability. If the vault is down, the proxy cannot fetch secrets. The mitigation is vault HA and a short-lived secret cache. The cache is a trade-off: it reduces vault load but increases credential exposure time.
Trade-offs vs. Direct API Calls
| Dimension | Treg Proxy | Direct API Calls |
|---|---|---|
| Setup time | Zero (catalog) or one-time registration (own-key) | Per-provider signup, key management |
| Cost | Per-call from a cent (catalog) or own-key (free) | Monthly subscription or per-call (varies) |
| Latency | +50-100ms proxy hop | Direct to provider |
| Credential exposure | Server-side only | Client-side or agent-side |
| API change impact | Update binding, agent unchanged | Update agent code |
| Observability | Centralized per-team dashboard | Per-provider logs |
The proxy adds latency. Every call goes through Treg before reaching the upstream. For latency-sensitive workloads, direct calls are faster. For agent workloads where setup time and credential management dominate, the proxy wins.
Technical Verdict
Use Treg when:
- Your agent needs dozens of APIs and you do not want to manage dozens of subscriptions
- You want to try a provider without signing up
- You need to share credentials across a team without distributing keys
- You want centralized observability for all tool calls
- You are building a multi-tenant agent platform and need per-team credential isolation
Avoid Treg when:
- You need sub-100ms latency to the upstream API
- You already have all provider subscriptions and credential management solved
- You need to inspect or transform upstream responses before they reach the agent
- You cannot tolerate a proxy in the critical path
- You need to call providers that require client-side OAuth flows (the proxy cannot complete those)
The architecture is clean. The relay-without-modeling design avoids the maintenance burden of wrapping every API. The two-tool model solves cold-start and team-sharing problems. The biggest operational challenge is keeping bindings in sync with upstream changes. If you can monitor and update bindings quickly, the proxy is a force multiplier for agent tool access.
Top comments (0)