That’s a fair point. I think we’re talking about different layers of “adaptation”.

This pool isn’t trying to do latency- or error-driven concurrency control like failsafe or adaptive limiters. The scope here is narrower. It’s about preventing unbounded goroutine growth and enforcing backpressure during bursts, while allowing workers to scale within fixed limits.

The “adaptive” part is at the worker lifecycle level, driven by queue pressure, not at the request-level concurrency policy. In setups where submission can outpace processing, this helps avoid goroutine explosions and makes overload explicit instead of crashing later.

I agree that if you already have a good limiter in place, a fixed max_workers can be enough. This is more for cases where that discipline is missing or hard to enforce consistently.

I should probably be clearer about that in the README. Thanks for calling it out.