Skip to content

Build1 publisher3 min readPublished

Scry's congestion pricing turns an agent's retry into a purchase

Scry's MCP search API prices an over-quota query instead of refusing it. That moves congestion control into the agent's retry loop, where a backoff timer cannot see the quote and the budget arbiter is the orchestrator's problem.

The Engineer · Build desk

Illustration accompanying Scry's congestion pricing turns an agent's retry into a purchase

What happened

  • Scry replaces hard rate limits with congestion pricing: an agent past its quota gets a price signal instead of a 429, and the agent or its orchestrator decides whether to pay or back off.
  • Its MCP server runs SQL-like queries over 164 billion rows indexed from Reddit, Hacker News, arXiv, Stack Exchange, Wikipedia and prediction markets.
  • According to the post, an agent that retries immediately into a price spike pays the high price, and many agents doing that amplify congestion instead of damping it.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • decision Anyone pointing more than one agent at a single Scry account writes the arbiter themselves, and decides in advance whose query gets denied when the price moves.
  • constraint Admitting on an estimate and settling on the actual means a spend ceiling only binds as tightly as the price is predictable across the life of one query.
  • exposure An agent given no budget will pay whatever the spike costs, and the charge lands on the shared billing account rather than on the agent that chose to retry.
  • contradiction The arbiter the post recommends needs a pre-execution price it describes conditionally, so the code may have to run on a guess it cannot check until after the query.

A 429 sheds load because the server never runs the query. Request 101 is refused, and the client's timer decides when it comes back [6]. Scry answers the same overload with a higher quote, and an agent that accepts the quote gets its rows [1][3]. A retry into a spike is a purchase. The work that raised the price stays on the server, and the post argues that many agents retrying this way amplify congestion instead of damping it [8].

The timer is the part that does not fit. Standard exponential backoff waits one second, then two, then four [7]. That is four attempts inside the first seven seconds [15]. No step in that ladder reads the quote, so a spike that outlasts seven seconds gets billed four times [3].

Scry does not enforce an arbitration model, so the orchestrator implements one; the post's own example is ten agents on one account with no arbiter, where the first agent awake can drain the budget [10]. Of the three models it describes, only the centralized arbiter comes with code [11]. BudgetArbiter approves a request when the estimated cost fits inside the remaining balance, decrements the balance by that estimate, and later calls refund, which adds (estimated_cost - actual_cost) back [12]. Admission runs on the estimate and settlement runs on the actual. When the actual is larger, that expression is negative, the balance ends at remaining minus the actual cost, and it can go below zero [16]. The spread between the two numbers is whatever the price did in between [3].

The estimate is where the design gets thin. According to the post, the agent can call /v1/scry/estimate if Scry exposes one, and otherwise has to fall back on historical cost data or a conservative upper bound [13]. The documented primitive is /v1/scry/schema, which returns the live schema and the current price for each relation [4]; the cost of a query that already ran arrives in its response metadata [5]. A conservative upper bound reserves more than the query will cost and hands the difference back only after execution [18]. Until that refund lands, the reserved money is denying someone else's query [12]. The sketch guards the balance with an asyncio.Lock and keeps it in an instance attribute, so the ceiling holds for coroutines inside one process; ten agents in ten processes need the balance somewhere all of them can see it [17].

The price has to reach whichever component decides, because an agent cannot react to a signal the orchestrator does not pass down [14]. The agent has to carry a budget, or it will pay any price [14]. And the backoff has to key on the price, which the post prescribes; its worked example stops mid-sentence at "If the price is 10x the baseline" [9]. The post gives no price curve, no elasticity figure, and no measurement of the amplification it warns about [19].

What to watch

  • Whether an SDK ships the dry-run call, which the post makes conditional on SDK support.
  • Whether Scry exposes the historical price distribution, so an agent can compare today's quote against its own baseline.
  • Whether anyone publishes a budget arbiter that keeps the balance in shared storage instead of one process's memory.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories