Corey James- 3 modesfor every admission limit, so a new one is watched before it refuses
- 3processes, agent calls, a scheduler and a poller, on one account-wide X limit
- 60%platform usage past which the Facebook poller skips its run
- 0daily caps of my own on the social modules
I built admission control into the memory service, the execution substrate's admission controller and a GPU decoder that refuses with a number rather than queueing silently. I decide where a limit sits by asking what the protected resource actually runs out of.
Pricing database work by its cost
FAFO Core and Function Forge lets agents call database-heavy functions over MCP, and agents submit as much work as you let them. The database has a fixed number of connections, a fixed write budget and fixed I/O, and the operations behind those functions range from zero-write reads to rewrites of a whole vector lattice.
One request-per-second limit cannot fit that range. I priced every request by its expected cost to the database, because database operations differ too much for a flat count to mean anything, and put that pricing in a dedicated Rust admission service in front of the governed data plane, so heavy work waits and cheap work flows.
Two shapes of third-party budget
The API integration platform I built beside Core applies the same thinking to third-party APIs, with one rule for reads and another for writes. Both buckets sit in Redis and read the Redis server's clock, so several consumer instances share one budget with no clock skew between them.
Watching a limit before it refuses
FAFOHive exposes the admission service and the bulk database writer to operators, and I wanted a new limit to be watched before it could refuse anything. Shadow mode runs a limit against real traffic and logs what it would have refused while refusing nothing; only then is it switched to enforcing.
One owner for each shared quota
The in-house X module had a different problem. Agent calls, a per-minute scheduler and a poller all draw on one account-wide platform rate limit and one budget, and each would believe it owned the whole allowance. I put one service in charge of the HTTP client, a sliding-window limiter, a concurrency cap, budget reservations, pacing, a circuit breaker and the write gate; the timers are thin clients that ask it to wake up. The design is deliberately small: no queue broker and no distributed workers.
The Facebook module puts the platform's own usage headers into every tool result, so its background poller can leave room for the agents. I removed the daily caps first set on the social modules and kept only the platforms' own limits, under my rule of no arbitrary limits.
OWNER
A decoder that refuses with a number
Capabilities model runs a tool-discovery decoder on an NVIDIA Blackwell GPU that also holds a large serving model. I made it admit work against measured free memory before accepting a request, and answer a full engine with a typed busy response that carries a retry hint. The story is A router beside a production model.
A refusal carries a type and a number the caller can act on; a silent queue or a timeout gives the caller nothing.