# Does it ever make sense to use Bundled workers at scale?

I’m trying to figure out if it ever makes sense to use bundled workers at scale.

For example, let’s say a worker receives 1 billion requests and every request is 50ms.

``````Bundled: (1,000,000,000 / 1,000,000) * \$0.5 = \$500
``````

But when using Unbound, 1 billions requests costs \$150, plus the memory usage.

Since every request is allotted 128 MB of memory and there’s 1 billion requests, that’s 128 billion MB of memory - or 128 million GB of memory.

We’re billed \$12.50/million GB-s, but each request is only 0.05 seconds (50ms), so each million GB should only cost 12.50 * 0.05 = \$0.625.

Since there’s 128 million GB being charged at a rate of \$0.625 each - that comes out to \$80 (128 x \$0.625) in memory charges.

``````Unbound: \$150 for requests + \$80 for memory = \$230
``````

In this example, Unbound costs half the amount of Bundled. Which just seems odd to me because we used 50ms which is the max time limit for Bundled.

If I used less than 50ms, the price of Bundled would stay the same, but Unbound would decrease even more. If I used higher than 50ms, Unbound would increase in price, but that would be the only option to use anyways since Bundled maxes out at 50ms and wouldn’t be useable.

I understand that for a lot of users, the amount of free requests included each month can make a difference. But when you’re using workers at scale (+100 million), the free requests make up such a small percent. So, at scale, would it ever make sense to us Bundled instead of Unbound?

If so, could someone give me an example if it making sense to use Bundled instead of Unbound (ignoring the free requests given for each plan).

Thanks for any clarify you guys can shine on this

EDIT: After doing a bit more math and calculating in all costs (like the \$5/month fee, plus the free requests for each plan), it actually looks like there’s never a reason to use Bundled instead of Unbound if you’re doing more than 14 million requests per month.

Chase

Your calculations look right. When Workers Unbound announced egress was charged at 0.09/Gb, then reduced to 0.045, then eventually phased out.
Unbound should give you a more granular billing, and a great pricing at scale.

I can’t remember the timing exactly but it’s like if you use less than 120 ms then Unbound wins. Otherwise Bundled makes more sense.

Remember Unbound is wall clock time so doing a fetch request which takes 100 ms does take a lot from that allocation. If it’s just doing small things though like maybe a KV get and some header changes then yes Unbound will win. If you’re doing more than that then Bundled likely comes out on top.

1 Like

Just to clarify that. The pricing difference skews in favor of Bundled if your wall clock time for the script (ie the real time it takes from start to finish) is greater than around 120ms. The CPU time (50ms vs 30s) is just the limit and represents how much time a CPU spends executing your script. Billing for Unbound happens based on wall clock time so slow I/O requests count. If I recall correctly, this can also come up subtly for example if you schedule I/O to happen after your request is complete in a waitUntil. Your script isn’t considered complete until everything is finished.

The only exception that matters to Unbound is if you don’t have any waitUntil and your Worker just acts as a pure proxy for WebSockets or sub requests (ie doesn’t process them in any way). In those cases billing will stop when you establish that proxy (ie effectively when you return the Response). See https://blog.cloudflare.com/workers-optimization-reduces-your-bill/ for a more detailed write up of how that works. It actually also applies to Durable Objects if I recall correctly but usually those kinds of Workers don’t act as proxies for anything.