# Scry: Congestion Pricing as Agent Rate-Limiting Infrastructure

> Source: <https://dev.to/mech_app_ai/scry-congestion-pricing-as-agent-rate-limiting-infrastructure-1gfo>
> Published: 2026-09-19 20:05:55+00:00

Scry is a programmable search API for agents that replaces hard rate limits with congestion pricing. Instead of getting a 429 when you hit a quota, you get a price signal. The agent (or its orchestrator) decides whether to pay more or back off. This shifts rate-limiting from a binary wall into an economic feedback loop.

The infrastructure question is not whether congestion pricing works in theory. It is how agents read and react to dynamic cost signals, how multi-agent systems arbitrate shared budgets, and whether retry logic amplifies congestion instead of damping it.

Scry exposes an MCP server that lets agents run SQL-like queries over 164 billion rows of indexed internet documents: Reddit, Hacker News, arXiv, Stack Exchange, Wikipedia, prediction markets. Agents query the underlying records instead of scraping search results.

The pricing model is congestion-based. When load spikes, the cost per query rises. When load drops, cost falls. The agent sees the price before it commits the query and can decide to proceed, defer, or cancel.

**Key primitives:**

`/v1/scry/schema` returns the live schema and current pricing for each relation.
This is not a token bucket. It is a spot market for query capacity.

Traditional rate limits are binary. You get 100 requests per minute. Request 101 gets a 429. The agent retries with exponential backoff or queues the request.

Congestion pricing replaces the binary with a gradient. The agent sees:

The agent can:

**Trade-offs:**

| Approach | Predictability | Burst Handling | Agent Complexity | Cost Control | 
|---|---|---|---|---|
| Hard rate limit | High | Poor (429 storms) | Low (retry logic) | Fixed ceiling | 
| Token bucket | Medium | Good (burst allowance) | Medium (token awareness) | Fixed ceiling | 
| Congestion pricing | Low | Excellent (price signal) | High (cost-aware logic) | Dynamic, requires budget arbiter | 

The agent needs cost-aware decision logic. If the orchestrator does not expose pricing signals to the agent, the agent cannot react. If the agent does not have a budget, it will pay any price.

When multiple agents share a single billing account, congestion pricing creates a coordination problem. Who gets to spend the budget when prices spike?

**Three arbitration models:**

**Centralized arbiter:** The orchestrator tracks cumulative spend and allocates budget to agents. Agents request permission before executing expensive queries. This adds latency but prevents budget exhaustion.

**Agent bidding:** Each agent declares a willingness-to-pay for each query. The orchestrator sorts by bid and executes queries until the budget is exhausted. This is efficient but requires agents to estimate query value.

**No arbiter:** Agents execute queries until the account balance hits zero. First-come-first-served. This is simple but can starve low-priority agents or blow the budget on low-value queries.

Scry does not enforce an arbitration model. The orchestrator must implement it. If you run ten agents on one account with no arbiter, the first agent to wake up can drain the budget.

**Implementation sketch for centralized arbiter:**

``` python
class BudgetArbiter:
    def __init__(self, total_budget: float):
        self.remaining = total_budget
        self.lock = asyncio.Lock()

    async def request_query(self, agent_id: str, estimated_cost: float) -> bool:
        async with self.lock:
            if estimated_cost > self.remaining:
                return False  # Deny
            self.remaining -= estimated_cost
            return True  # Approve

    async def refund(self, actual_cost: float, estimated_cost: float):
        async with self.lock:
            self.remaining += (estimated_cost - actual_cost)
```

The arbiter needs cost estimates before execution. If Scry exposes a `/v1/scry/estimate` endpoint, the agent can call it before requesting approval. If not, the agent must use historical cost data or a conservative upper bound.

Standard retry logic uses exponential backoff tied to time. If a request fails, wait 1 second, then 2, then 4. This works for transient failures but not for congestion pricing.

If the price spikes and the agent retries immediately, it pays the high price. If the agent waits and the price is still high, it retries again. If many agents do this, retries amplify congestion instead of damping it.

**Cost-aware backoff:**

The SDK needs to expose price history or a price trend signal. Without it, the agent is blind.

**Example backoff logic:**

``` python
async def query_with_backoff(query: str, max_cost: float, max_retries: int = 5):
    for attempt in range(max_retries):
        price = await scry.get_current_price(query)
        if price <= max_cost:
            return await scry.execute(query)

        # Exponential backoff scaled by price ratio
        price_ratio = price / max_cost
        wait_time = min(2 ** attempt * price_ratio, 300)  # Cap at 5 minutes
        await asyncio.sleep(wait_time)

    raise Exception("Query cost exceeded budget after retries")
```

This prevents the agent from hammering the API during price spikes. But it requires the SDK to expose real-time pricing.

Congestion pricing makes cost attribution critical. If an agent runs 1,000 queries and the bill is $500, which queries were expensive? Which agents are burning budget?

**Required observability:**

If the orchestrator does not log per-query cost, you cannot debug budget overruns. If you cannot correlate cost with query type, you cannot optimize agent behavior.

Scry returns cost in the response, but the orchestrator must log it. If you use LangChain or a similar framework, you need a custom callback to capture cost metadata.

Scry runs as an MCP server. The agent (ChatGPT, Claude, Cursor, any MCP client) connects to `https://mcp.scry.io`. No local infrastructure. Sign-in creates the account.

**Failure modes:**

**Security boundaries:**

Congestion pricing works when:

It does not work when:

Use Scry if you are building multi-agent systems that need large-scale internet search and you can implement cost-aware orchestration. The congestion pricing model is a better fit for agent workloads than hard rate limits, but only if your orchestrator can track spend, arbitrate budgets, and expose pricing signals to agents.

Avoid it if your agents cannot defer queries, you need predictable costs, or you are running a single agent with simple retry logic. In those cases, a fixed-rate API with token buckets is simpler.

The infrastructure gap is observability. Scry returns cost per query, but you need to log it, aggregate it, and feed it back into agent decision logic. If your orchestration layer does not do this, you will burn budget without knowing why.