OpenAI Rewrote Habitat From Python to Rust With Just 2 Engineers

OpenAI just told a story that reads like a fantasy for anyone who has ever sat through a six-month, twelve-engineer migration plan: two engineers, aided by AI coding tools, rewrote a storage platform handling more than 20 million requests per second — and shipped a version that is now carrying 95% of production traffic. The system in question is Habitat, OpenAI's internal online storage platform, and the language change was Python to Rust.

The headline numbers — 6x CPU efficiency, 15x memory efficiency — are the kind of figures that get screenshotted and rerun through every "AI replaces engineers" argument on X within hours. But the actual lesson for practitioners is narrower and more useful than that: Python hit a specific, well-understood wall at extreme scale, and OpenAI used AI coding assistance to compress the calendar time of fixing it, not to eliminate the need for engineers who understood the problem. Here's what actually happened, why Python hit its limits, and what any of this should change about how you plan your own infrastructure work.

TL;DR — Habitat's Python-to-Rust rewrite

What Habitat actually is

Habitat began, per OpenAI's account, as a simple Python client library that let internal teams read and write data without building their own storage plumbing. As ChatGPT and the API grew, Habitat grew with them — evolving into the shared data-access layer sitting between every OpenAI product and the storage systems underneath it.

The architecture OpenAI describes puts Habitat in the middle of the request path: clients — ChatGPT, the API, Codex, and internal services — talk to Habitat, which handles caching, ACL-based authorization, data placement and residency, encryption, multi-tenant isolation, rate limiting, and routing before the request ever reaches a storage backend like Azure Cosmos DB, an internal system OpenAI calls Nanobase, Valkey caches, or blob storage. A separate change-data-capture (CDC) path feeds updates into Databricks, Rockset, and Kafka for analytics and downstream consumers.

That's a lot of responsibility to centralize in one service. It's also exactly the kind of shared infrastructure layer where a performance ceiling doesn't just slow one team down — it caps throughput for every product built on top of it, which is presumably why OpenAI cared enough to rewrite it rather than patch around it indefinitely.

Why Python hit its limits — the teaching moment

This is the part worth understanding even if you never touch Habitat. Python's reputation for being "slow" at scale usually gets attributed vaguely to "the GIL" without explaining what actually breaks. OpenAI's account is more specific, and the specifics generalize to a lot of growing platforms.

The Global Interpreter Lock (GIL) isn't the only story. The GIL prevents multiple threads from executing Python bytecode simultaneously in one process, which is why CPU-bound Python workloads don't scale across cores the way Rust or Go do. But Habitat is I/O-bound, not CPU-bound in the classic sense — it's mostly waiting on network calls to storage backends — so async Python (asyncio) was the right initial tool, not threading. The GIL still matters here, but indirectly: it means a single Python process can only make so much progress on background bookkeeping (like refreshing config) while also serving requests, before that bookkeeping starts stealing scheduler time from the actual request path.

Event-loop management became the bottleneck. OpenAI's tweets specifically call out "event-loop management" as a challenge at scale. In practice, this shows up as periodic background tasks — like reloading a feature-flag configuration on a timer — that were not staggered ("jittered") across worker processes. When every worker on every pod reloads its config in the same second, they all briefly stall the event loop at once, producing synchronized latency spikes across the whole fleet instead of one slow worker you can route around.

Connection pooling amplified the failures. The second challenge OpenAI names is connection pooling. A connection pool's reuse policy decides which idle connection gets picked for the next request. A last-in-first-out (LIFO) policy — the common default — tends to favor whichever connection returned most recently, which under load means slower, already-struggling backend servers get more traffic routed to them, not less, because their connections are the ones sitting idle waiting to be reused. That's a feedback loop that gets worse exactly when you need it to self-correct.

None of these are exotic problems. They're the standard failure modes of running async Python past the point where its cooperative scheduling model was designed to hold up — and they only bite at genuinely extreme concurrency. Most services never get close to 20 million requests per second, which is the caveat that should follow you through the rest of this post.

The rewrite: 2 engineers, AI coding assistance, 6x/15x gains

OpenAI's headline claim is that a two-person team, using AI coding assistance, rewrote Habitat's service layer in Rust and shipped it into production carrying 95% of traffic — with 6x CPU efficiency and 15x memory efficiency over the Python version, plus lower latency.

Frame those efficiency numbers the way you'd frame them for your own infrastructure bill, not as trivia. A 6x CPU reduction on a service handling tens of millions of requests per second doesn't mean "the code runs faster" in the abstract — it means OpenAI can serve the same load on roughly a sixth of the compute, and the same request rate on about a fifteenth of the memory footprint. At cloud-infrastructure pricing, that's the difference between a line item that keeps growing with usage and one that plateaus. If your own service is CPU- or memory-bound at real scale, that's the actual number to go model against your own cost curve before deciding a rewrite is worth doing — not the "AI wrote it fast" headline.

The staffing number is the part getting the most attention, and it deserves the most skepticism. A rewrite of this scope — a shared storage platform underneath ChatGPT and Codex — normally implies a multi-quarter project with a dedicated team, careful dual-write migration phases, and extensive load testing before a single percentage point of production traffic moves over. OpenAI is claiming AI coding assistance compressed that into something two people could execute. That's plausible for the code-writing portion of a migration — a lot of a rewrite like this is mechanical translation of well-understood logic, exactly the kind of work coding agents have gotten good at through 2026. It's much less obviously true for the migration engineering — the dual-write period, the rollback plan, the load testing against real production traffic patterns — which tends to be where rewrites actually die, and which OpenAI's public post doesn't detail in the same depth as the language-level lessons.

What this means for how you staff a similar rewrite

The practical takeaway isn't "use AI to rewrite your stack with two people." It's narrower: AI coding assistance changes the ratio of what a small team can attempt, specifically for well-scoped, well-understood migrations where the target behavior is already defined by the system you're replacing. A rewrite where "correct" means "behaves exactly like the existing Python service, just faster" is a much better fit for AI-assisted small-team execution than a rewrite that also has to design new behavior. Habitat's team knew exactly what Habitat was supposed to do — they'd been running it in Python for years. That's a very different starting position than a greenfield project.

If you're scoping a similar move, the honest staffing question isn't "how many engineers does OpenAI say they used" — it's "how much of my rewrite is translation of known-correct logic versus design of new behavior." The more it's the former, the more a small, AI-assisted team is a reasonable bet. The more it's the latter, this case study tells you nothing about your timeline.

What people are asking

Should I rewrite my Python service in Rust? Only if you've actually measured a CPU or memory bottleneck under real production load that async optimizations, better connection-pool tuning, or horizontal scaling can't fix first. Habitat's team hit this wall at 20 million-plus requests per second — a scale almost no service reaches. Rewriting a service that isn't actually bottlenecked trades a working system for engineering risk with no guaranteed payoff.

When does the GIL actually become a bottleneck? When your workload has meaningful CPU-bound work competing with I/O-bound async code in the same process — background jobs, JSON parsing, serialization — at high enough concurrency that scheduler contention becomes visible as latency spikes. Pure I/O-bound async services (most typical web backends) rarely hit this; Habitat's issue was specifically background bookkeeping tasks stealing event-loop time from request handling, not the GIL blocking raw throughput directly.

Can two engineers really do this without AI help exaggerating the story? There's no way to independently verify OpenAI's staffing claim — it's a number from the same company marketing its own AI coding tools, disclosed in a blog post whose secondary purpose is demonstrating that Codex and GPT-5.5 can do serious production engineering. That doesn't make it false, but it does mean it should be read as a case study with an obvious incentive to look impressive, not as an audited engineering report.

Does the 95%-of-traffic figure mean Python is fully gone? Not necessarily — 95% of production requests going through the Rust service still leaves a tail of traffic OpenAI hasn't or can't migrate yet, which is common in staged rollouts where the last few percent are the hardest edge cases. OpenAI's post doesn't specify what the remaining 5% consists of.

The honest caveats

Every number in this post — 500 petabytes, 20 million-plus requests per second, 10x year-over-year growth, 6x CPU and 15x memory efficiency, 95% of traffic, and the two-engineer team — comes from OpenAI's own announcement. None of it is independently audited. That's not unusual for a company blog post, but it matters more here because the post is simultaneously a technical retrospective and an implicit advertisement for the AI coding tools OpenAI sells.

There's also a survivorship-bias problem worth naming directly: we don't hear about the AI-assisted rewrites that failed, got rolled back, or quietly took twice as long as planned. A single successful case study from the company most incentivized to publish successful case studies about its own AI tools is evidence, but it's the least representative kind — success stories self-select in a way failure stories never get the chance to. If you take one thing from this piece, take the Python-scaling lessons — the event-loop jitter problem and the LIFO-versus-FIFO connection pool issue are real, reusable, and true regardless of who wrote the fix or how fast they wrote it. Treat the "two engineers did it all" framing as a marketing-adjacent claim to file separately from the engineering lesson, not as a staffing benchmark for your own team.

This pattern of AI coding agents doing real production engineering inside frontier labs isn't isolated to Habitat — see explainx.ai's coverage of OpenAI's own research-acceleration numbers, where the company reports its researchers now run over 3 agent-workdays of coding-agent effort per human workday, with the same self-reported caveats that apply here.

Related reading

• Perplexity Joins the Rust Foundation to Back SPACE, Its Agent Sandbox — a second AI company committing to Rust infrastructure the same week, this time for agent sandboxing rather than storage
• OpenAI's Research Acceleration Post: 3.1 Agent-Workdays Per Human — OpenAI's own internal data on how much coding-agent work its researchers now run, with the same self-reported-numbers caveat
• Turso: SQLite Rewritten in Rust — Complete Guide — another storage system that moved to Rust for performance, with a different (open-source, incremental) migration story
• How Cloudflare Saved 100 Terabytes Optimizing Its DNS Cache — a comparable hyperscale infrastructure efficiency rewrite, this one in-place rather than a language change
• Should You Manually Retype LLM-Generated Code? The HN Debate — the counterpoint: does AI-assisted code at this speed cost the team its own understanding of the system it just rewrote?
• ChatGPT Work vs Codex: What Actually Changes — Codex is one of the products Habitat serves data to; how OpenAI positions Codex today
• Meta's 73.7 Trillion Token Month: Costs, Tokenmaxxing, and What Spotify & Shopify Do Instead — how other large engineering orgs measure AI-assisted engineering, outcomes vs. volume
• Design Docs Are All You Need: SMART Turns Specs Into Regenerable ML Perf Code — a research approach to regenerating performance-critical code from specs, a related idea to translating known-correct logic into a new language
• OpenAI's official announcement: Rapidly scaling online storage to serve over 1 billion ChatGPT users

Figures in this article — 500+ petabytes, 20 million-plus peak requests per second, 10x year-over-year growth, 6x CPU efficiency, 15x memory efficiency, 95% of production traffic, and the two-engineer team size — are OpenAI's own reported numbers as of its September 2026 announcement and have not been independently verified by explainx.ai. Details are accurate as of the publication date; OpenAI may update its own post or migration status afterward.