Queues and rate limits in security work

A recon run, a long reverse-engineering session or an agent loop during an engagement window does not fail at the price. It slows down when a provider caps how many requests run at once, queues them, or lets a speed reserve run down. The bill stays the same while the job finishes late, and a late job is what a client window penalizes.

Each service publishes its throughput rules somewhere, but most buyers read the price first. This post sets out what four services say about their own limits. Verboo's figures come from its home page and Terms of Use, collected on 11 November 2026. Venice's come from its pricing page and Terms of Service, and Drael's from its limits page, collected on 9 and 10 November 2026. NotHoly's figures come from its pricing page. These are rules on paper. None of them is a measured wait, and none says how a service behaves on a given day. Check the pages again before you buy.

#Throughput terms side by side

Each row is one service's published rule, as the sources above describe it.

Service	What it publishes about throughput	Source and date
Verboo	Unlimited tokens on its two higher plans, but the terms exclude guaranteed speed. Concurrency, request rate and throughput may be limited, with queuing and tier-based priority reserved. A stamina reserve slows replies as use grows.	Terms of Use, version 2.4, dated 30 September 2026
Venice	An API billed per token on top of a monthly plan whose credit expires. The consumer terms let Venice revoke keys at any time.	Pricing page and Terms of Service, updated 8 June 2026
Drael	Four answers at once per account, across all keys. A fifth request gets a 429 that the docs say is not retried for you. The per-minute rate is not published.	Limits page, collected 9 and 10 November 2026
NotHoly	Prepaid credit metered per token, with no subscription and no stamina reserve. Rate limits are set per key in the console.	Pricing page and console

#What Verboo's terms reserve

Verboo's home page sells unlimited tokens on its two higher plans, at a fixed price. Clause 8 of its Terms of Use says that unlimited does not mean unlimited compute, uninterrupted availability or guaranteed speed.

Clauses 8.1 and 20 reserve the right to limit concurrency, request rate and throughput, and to apply queuing, tier-based prioritization and wait times. Clause 9.6 lists circumventing rate limits or queues among prohibited uses, so the terms treat the queue as a control Verboo can use. The terms do not say when a queue applies. Whether it applies to a given account, and when, is at Verboo's discretion and is not published.

On the paid plans the site also describes a stamina reserve. It slows responses as use grows and recovers when you pause. The site says running out of stamina does not block you, so the effect is a slower reply. Verboo vs NotHoly compares the plans and prices.

#What Venice and Drael publish

This post does not compare Venice's rate or queue rules, because we have not collected them yet. What we have is the cost side of a long run. The US$ 18 plan includes US$ 1 of API credit, and that credit expires with the month. Venice's consumer terms also let it revoke keys at any time, which matters when an agent loop is halfway through an engagement window. Venice vs NotHoly has the per-token rates on the bases both catalogues share.

Drael's limits page is the most specific of the four. Each account gets four answers at once, across all of its keys. A fifth request gets a 429, and the page says it is not retried for you. To scale, the page suggests spreading work across separate accounts, each with its own subscription. The per-minute rate is not published, because the page says it is set against real usage. Inside the plan, use is described as unlimited in volume within fair use, and the page does not say where fair use ends.

The same page describes the shared machine behind the service. Everyone served at the same moment shares one machine, so a busy minute is slower for everyone in it. Priority on a plan decides your place in line. It does not make an answer faster. We found no published capacity figure or SLA on that page.

#How NotHoly handles throughput

NotHoly bills prepaid credit per token. There is no subscription, so no stamina reserve runs down, and there is no plan tier to place behind another. Rate limits are set per key in the console, so a batch runs under a cap you chose for that key. The credit does not expire, and pricing lists the per-token rate for each model.

A per-key limit caps your own use. It says nothing about how fast a model answers on a given day. This post gives no speed, uptime or capacity number for NotHoly, so measure your own workload before you rely on it.

#Where a queue is a reasonable trade

Steady, interactive use can suit a flat monthly bill. A reserve that slows replies as use grows bothers you less when nothing is due that hour. Our view is that the cost lands on long, bursty or deadline-bound runs: a decompiler pass over a large binary, a triage queue at the end of a week, an agent that has to finish before a report is due. In those runs a slow reply compounds, and the total shows up in elapsed time, not in the line on the invoice.

#Questions to put to any provider

Put these four questions to every provider, NotHoly included:

• Is the price a fixed quota, or does a speed reserve apply?
• Are concurrency and rate limits published, with their numbers?
• Can the provider queue your plan or lower its priority?
• Is latency measured against a published target?

#Does the stamina reserve stop a run?

According to Verboo's own site, no. Running out of stamina does not block a request. The result is a slower reply. A slow reply still counts against a deadline, so the reserve affects timing even when nothing is refused.

#Does NotHoly promise speed?

No. This post gives no speed, uptime or capacity figure for NotHoly. Per-key limits restrict how much your key sends. They do not set how long a call takes to return.

#Verdict

Verboo sells a fixed price and reserves queuing, prioritization and slowdowns for heavy use, and its terms say so. Drael publishes the most specific limits of the four: four answers at once per account, a 429 on the fifth request, and a shared machine. Venice's rules that matter for throughput are not compared here. NotHoly bills tokens and sets rate limits per key in the console, with no stamina reserve, but this post gives it no speed figure. For a long run, check the clock as well as the total. Price the run on pricing, then test the limits on your own workload.