Compatibility at the SDK boundary can lower migration friction, but a wrapper’s behavioral contract—not its familiar client syntax—determines how portable an application really is.
ECW adapts E2B-shaped requests to SPACE operations where behavior aligns and rejects or limits capabilities SPACE cannot honor. The documentation says it translates E2B-compatible HTTP requests into SPACE operations and is separate from the SPACE API. The documented tested baseline is Python e2b==2.21.1 and e2b-code-interpreter==2.6.2; other releases and JavaScript may work but are not covered by current compatibility tests. Its contract includes specified sandbox lifecycle flows and selected command, filesystem, watch and port operations, while limitations include volumeMounts, iam, and network.allowPublicTraffic=true.
Teams selecting a sandbox runtime can consider SPACE without first replacing every E2B-shaped integration, while the published limits make migration risk more inspectable. Builders can assess a backend transition against concrete operations rather than assume SDK compatibility means parity. The repository documentation establishes the intended contract and tested package versions, not independent interoperability results or production reliability. Whether future compatibility tests broaden the supported SDK versions and client languages. No prior New Runtime record was supplied; this begins a distinct analytical record on SDK compatibility as a migration surface.