That’s probably where my different expectation comes from.
There it states …
Workers connected to one another via Service bindings share the CPU resources of the top-level request. A single thread is allocated and reused amongst these Workers. This means no idle resources are wasted while work is performed across various Workers.
Hence no extra resources should be required.
Either way, it’s understandable and I don’t want to argue about 's pricing.
It’s simply a bit sad from a software architecture POV, as small workers calling each other would be great regarding the “low coupling, high cohesion” design principle. The price incentive OTOH strongly nudges one towards (comparatively) larger, more monolithic Workers.
And from a pure performance POV many subrequests from the same main worker is likely not even that smart, as even fetch() to another “nearby” Worker will be much more expensive than a simple local JS function call.
Monolithic workers can be reasonably solved by trunk based development techniques and a CI/CD pipeline setup with some hand tuned bundling strategies. Minimize chunk count and chunk size limit, for example, are staples of virtually every modern bundler.
The crux is that most SME have neither time nor expertise to properly setup such infrastructure and will be stuck on higher than necessary cost from either Cloudflare bills or code maintenance efforts.
So I as well look forward to a rework of what would be a great help for many of these small development teams.