Contents
- The short answer
- How we checked this
- What GA actually shipped
- Fixed: package installs
- Claimed but unconfirmed: OpenAI SDK and LangChain
- Still no numbers: cold starts and speed
- Not fixed: requests still hang on streaming responses
- FAQ
Beta testers had four main complaints about Python Workers: no package installs, an awkward OpenAI SDK, no speed numbers, and requests that hang for no clear reason. Cloudflare took the framework out of beta on September 21, 2026, and says most of that is history now. We checked each complaint against Cloudflare’s own GA docs, its blog post, and an open GitHub issue filed five days before launch. Three look addressed, on the vendor’s own word. One does not, and there’s a bug report to prove it.
The short answer
Package installs: fixed, per Cloudflare’s docs. OpenAI SDK and LangChain: claimed fixed, but only Cloudflare has said so. Cold start speed: still no public numbers, before or after GA. Hanging requests: not documented as fixed anywhere we checked, and a matching bug was still open two days after launch.
That’s the whole picture in four lines. The rest of this piece is how we got there, and what each answer actually rests on.
How we checked this
We didn’t take Cloudflare’s word for any of this without opening the sources ourselves. Checked at 2026-09-23, 01:11 KST.
The method was simple: open the original beta complaint (mkdev.me, published 2025-06-09) and pull its exact wording. Then open Cloudflare’s current package docs page (last updated 2026-09-18) and the GA announcement (published 2026-09-21), and pull their wording on the same two topics. Line them up side by side.
| Point in time | Source | Package installs | OpenAI SDK / LangChain |
|---|---|---|---|
| Beta, 2025-06-09 | mkdev.me | “you can’t install any packages today” | worked around a clunky SDK with raw HTTP calls |
| GA docs, updated 2026-09-18 | Cloudflare docs | supports pure and PyEmscripten packages on PyPI | not mentioned on this page |
| GA blog, 2026-09-21 | Cloudflare | packages install through the new PyEmscripten wheel format | “run AI libraries like openai, langchain, and mcp natively” |
The headline figure from this check: GitHub issue cloudflare/workers-py#262 was opened on 2026-09-16, five days before GA, and was still open when we checked on 2026-09-23, two days after launch. That’s the bug we get into further down.
One catch worth flagging up front: both GA-side claims in that table come from Cloudflare’s own docs and blog. No independent third party has republished a working openai or langchain Python Worker to confirm the SDK claim end to end.
What GA actually shipped
A few background facts, straight from Cloudflare’s own announcement. PEP 783, the standard that lets Python packages target browser and WebAssembly runtimes, was accepted after what Cloudflare describes as “over a year of discussion and refinement.” Cloudflare built on that with cibuildwheel integration, so package maintainers can compile PyEmscripten wheels.
On the framework side, GA adds FastAPI, Django, and Flask support through built-in workers.asgi and workers.wsgi connectors — Cloudflare’s language is “any Python web framework that uses the WSGI or ASGI interface.” Database access runs through Hyperdrive, with PostgreSQL and MySQL support via drivers like aiomysql and asyncpg.
Under the hood, nothing about the execution model changed at GA. Python still runs through Pyodide — CPython compiled to WebAssembly — inside the same V8 isolates that run JS Workers, with no separate compile step.
Cloudflare’s framing is that Python is now “a first-class, fully supported language on the Cloudflare Developer Platform,” wired into Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, and Workflows. That’s a lot of surface area.
My read: that’s a real platform commitment, not a checkbox launch. Whether it holds up in practice is a separate question, which is the point of the rest of this piece.
Fixed: package installs
This was the loudest beta complaint. The mkdev.me reviewer, writing on 2025-06-09, put it bluntly: “you can’t install any packages today.” That’s a dead end for almost any real service.
What changed by GA (2026-09-18 docs, 2026-09-21 blog):
– Packages install via pyproject.toml, targeting the new PyEmscripten wheel format – Tooling moved to uv plus pywrangler —
uv run pywrangler devordeploy– Dependencies get bundled with the worker automatically on deployment – Coverage: pure Python packages and PyEmscripten wheels already on PyPI
That’s a genuine fix, not a workaround. But its own docs page carries a hedge worth repeating word for word: “WebAssembly support for Python packages is still in early stages, and some packages may not yet be available as PyEmscripten wheels on PyPI.” In other words, the mechanism works, but the ecosystem behind it is still catching up.
If your project depends on a package that hasn’t shipped a PyEmscripten wheel yet, you’re back to the beta-era wall — just for a narrower set of libraries than before.
Claimed but unconfirmed: OpenAI SDK and LangChain
The second complaint was narrower but just as painful for anyone building AI features. The same mkdev.me review said the OpenAI Python SDK “felt odd” to use, and the reviewer ended up making raw HTTP calls instead of using the SDK as intended.
Cloudflare’s GA blog post, published 2026-09-21, states plainly: “You can now run AI libraries like openai, langchain, and mcp natively in Python Workers.” The mechanism, per the same post, is upstream patches to requests and httpx that route through the JS fetch API, plus new socket operation support.
Here’s the catch other coverage tends to skip: the reference docs — not the marketing post — don’t mention OpenAI or LangChain at all. The claim lives only in the blog.
We couldn’t find any independent republication of a working openai or langchain Python Worker. That includes explainx.ai’s GA writeup, which is the one third-party piece we reviewed on this launch — it says independent benchmarks and tests “weren’t available as of publication.”
So: claimed fixed, by the vendor, with a plausible technical explanation attached. Not yet confirmed by anyone outside Cloudflare. Those are different things, and it’s worth keeping them separate before you build on it.
Still no numbers: cold starts and speed
Complaint three was that Python Workers felt slower than the JS equivalent. This is the one where GA brought no evidence either way.
We read the full text of the GA blog post and the “How Python Workers work” docs page looking for any benchmark, millisecond figure, or JS-versus-Python comparison. We found zero.
The docs page does describe a mechanism: Cloudflare executes the worker’s entrypoint and top-level imports at deploy time, snapshots the resulting WebAssembly linear memory, and loads that snapshot at request time instead of re-initializing from scratch. That’s a real architectural choice aimed at cutting cold-start cost. But the same page just defers further detail to “the blog post introducing Python Workers” — which points back to the original 2024 beta-era announcement, not to any new GA-era measurement.
We didn’t run our own cold-start benchmark. We didn’t find one anywhere else, either.
Worth saying plainly: we’re not building a Cloudflare Python Workers vs. AWS Lambda Python pricing and feature comparison table here — the numbers needed for a fair comparison simply aren’t public yet, and a guessed table would be worse than none.
Not fixed: requests still hang on streaming responses
This is the complaint that matters most if you’re deciding whether to ship on this today.
The original beta report described it this way: “Requests would get stuck or timeout without any clear reason. Where it was supposed to wait for the request to finish, it would not.” That’s the kind of bug that erodes trust fast, because it doesn’t fail loudly — it just sits there.
We found a GitHub issue that matches the symptom almost exactly. cloudflare/workers-py#262, titled “workers-runtime-sdk 1.8.4: ASGI streaming responses pass a borrowed Future proxy to waitUntil,” was opened by a user named HoddyChen on 2026-09-16 — five days before GA shipped.
The mechanism, per the issue: a Python Future handed to JS’s waitUntil() as a “borrowed proxy” gets destroyed before JS finishes using it, which throws a runtime error on streaming responses and FastAPI middleware. That’s the same class of hang the beta reviewer hit.
The issue’s author notes that the main branch has already reworked process_request() to create an explicit proxy before calling waitUntil() — but says that fix is absent from the deployed runtime-sdk version, 1.8.4, that pywrangler currently injects.
As of our check on 2026-09-23, two days after GA, the issue carried no closing commit, no release note, and no maintainer confirmation.
One honest complication: the workers-py package on PyPI is at version 1.17.4, released 2026-09-21 — GA day. That version number doesn’t map cleanly onto the “workers-runtime-sdk 1.8.4” cited in the issue, so we can’t confirm from what’s public whether the package you’d install today actually contains the fix. That’s a gap in the record, not a claim either way.
This is also the one complaint Cloudflare’s GA materials don’t address anywhere we could find. Not a mention, not a changelog line.
If you’re building anything that streams a response — think FastAPI with StreamingResponse, or middleware in that path — test it directly before shipping. Hit the symptom yourself? Checking it against #262 beats guessing.
My honest take: I wouldn’t put a production streaming endpoint on Python Workers yet. The other three fixes look real. This one still has an open ticket with your name on it if you’re unlucky enough to hit it.
FAQ
Is Cloudflare Python Workers GA actually stable enough for production? It depends what you’re building. Package installs and framework support (FastAPI, Django, Flask) look solid based on Cloudflare’s own GA docs. But the streaming-response hang described in issue #262 was still open two days after GA, and Cloudflare hasn’t documented it as fixed anywhere we checked — so anything involving streamed or long-running responses deserves testing first.
Do openai and langchain really work in Python Workers now? Cloudflare’s GA blog says yes, and describes a plausible mechanism — HTTP client patches routing through the JS fetch API. But that claim hasn’t been independently confirmed by anyone outside Cloudflare as of this check, and Cloudflare’s own reference docs page doesn’t even mention it. Treat it as claimed, not verified.
How much faster is Python Workers at GA compared to beta? Unknown — Cloudflare hasn’t published any cold-start or speed figures for GA, and none existed for beta either as far as we found. The docs describe a memory-snapshot mechanism meant to cut initialization cost, but there’s no number attached to it anywhere in the GA announcement or the technical docs page.
What happens to issue #262 next is the thing worth watching. If it closes with a release note tying it to a specific workers-py version, that answers the one open question in this piece. Until then, the honest summary is three fixes confirmed by the vendor and one bug still sitting open in public.
Image credits
- Cf-logo-v-rgb by <a href=”//commons.wikimedia.org/w/index.php?title=User:Kean, licensed under CC BY-SA 4.0 (via Openverse)