E2B's Python SDK 2.56.0 removes a guessed client-side number from a critical path: the number of concurrent HTTP/2 streams allowed on each connection to a sandbox. The transport now takes that limit from the server's own HTTP/2 settings and opens another connection only when every existing one is full.
## What changed
The October 13 release replaces E2B's Python-side balancing across multiple transports with `pyqwest`'s native connection pool. `E2B_STREAMS_PER_CONNECTION` is gone. Capacity now comes from the peer's `SETTINGS_MAX_CONCURRENT_STREAMS`; `E2B_MAX_CONNECTIONS` remains the outer cap, with a default of 200 connections per resolved address.
This is a transport change, not an agent API redesign. Commands, filesystem operations, PTY traffic and health probes continue through the SDK's shared stack. The same release raises the Python floor from 3.10 to 3.11 and declares `pyqwest>=0.12,<0.13`.
## Why it matters
Long-lived command and watch streams can occupy HTTP/2 slots for much longer than ordinary requests. A fixed client assumption can underfill a server that allows more streams or overload an intermediary that allows fewer. Reading the negotiated server limit makes the client react to the path it actually has rather than a tuning constant copied from today's production setup.
That improves capacity handling, but it does not create workload admission control. A pool allowed to open as many as 200 connections can still put substantial pressure on a host. Operators upgrading should remove any dependence on `E2B_STREAMS_PER_CONNECTION`, review `E2B_MAX_CONNECTIONS`, and account for the Python 3.11 requirement.
## Direct verification
I checked out the annotated `@e2b/python-sdk@2.56.0` tag; it resolves to commit `62a17dfc3f11439d1d06bfb9bb515eadc5adfcd3`. The tagged package metadata reports version 2.56.0, Python 3.11 or newer, and `pyqwest` 0.12.x. PyPI reports uploads on October 13.
On Windows with CPython 3.13, I ran six focused transport/configuration modules from that tag:
- `test_api_client_transport.py`
- `test_envd_client_transport.py`
- `test_envd_stream_capacity.py`
- `test_shared_transport_pool.py`
- `test_connection_config.py`
- `test_env_var_parsing.py`
Result: **118 passed in 14.51 seconds**.
The tests use local HTTP/2 frame servers. The capacity cases open waves of long-lived streams, verify that new connections appear only after the advertised stream limit is reached, and verify that released slots are reused. The shared-pool cases distinguish an HTTP/2 stream reset—which leaves the connection usable—from a dropped TCP connection, which must be redialed before a health probe.
## Boundary of the check
I did not exercise E2B Cloud, authenticated sandbox creation, TLS/ALPN negotiation, or a production intermediary. The result verifies the tagged local transport behavior and its regression tests, not production throughput or service-level behavior.