HTTPX2 Is a Ground-Up Rewrite: What Changes for Python HTTP Clients

The Big Bang: What Actually Happened with HTTPX2

The Python HTTP client landscape just got a seismic shake. The team behind Pydantic has released HTTPX2, and it’s not a minor version bump or a patch with some performance tweaks. It is a complete, ground-up rewrite of the original httpx library. The repository lives at pydantic/httpx2 on GitHub and the README is refreshingly blunt: the existing httpx codebase had architectural limitations that could not be fixed incrementally.

For engineers who have been using httpx for years—often as a modern drop-in replacement for requests with async support—this is a critical moment. The library you know is effectively entering maintenance mode. All new development energy is flowing into HTTPX2. If you are building scrapers, API gateways, or high-concurrency data pipelines in Python, you need to understand what changed, why it changed, and how to navigate the transition.

The Core Shift: Async-Native Architecture

The single biggest architectural change is that HTTPX2 is async-native. The original httpx bolted async support onto a synchronous core. This led to subtle bugs, complex code paths, and a ceiling on performance optimizations. HTTPX2 flips the model: the entire connection lifecycle, from DNS resolution to TLS handshake to stream processing, is built on an async foundation. The synchronous API you might be used to is now a thin convenience layer on top of the async engine.

Here’s the mental model shift:

This design eliminates the sync/async schism that plagued the original library. For an engineer debugging a production issue at 2 AM, this means you no longer have to wonder if a deadlock is caused by mixing sync and async calls under the hood. The code paths are unified.

Why This Matters for Forward Deployed Engineers

If you are a Forward Deployed Engineer (FDE) building integrations at enterprise customers, HTTP clients are your bread and butter. You are constantly writing code that hits customer APIs, scrapes internal tools, or streams data from legacy systems. The original httpx was often the right tool for the job because it handled both the quick synchronous script and the high-throughput async worker.

HTTPX2 changes the calculus in three ways that directly impact an FDE’s daily workflow:

1. Simpler Concurrency Models: When you are building a prototype that needs to fan out to 50 internal microservices, you can now write pure async code without worrying about whether the underlying library is secretly blocking the event loop. This makes the handoff from prototype to core engineering smoother—something we cover in depth in our guide on scaling yourself and handing off a prototype.

2. Fewer Dependencies: HTTPX2 strips out a lot of the C-extension and third-party dependency complexity. For an FDE deploying into a customer’s restricted air-gapped environment, fewer dependencies mean fewer security review headaches and less time wrestling with pip install failures.

3. HTTP/2 as a First-Class Citizen: The original httpx supported HTTP/2 but with caveats. HTTPX2 treats HTTP/2 as a foundational protocol. If you are building a data pipeline that streams results from a modern API, multiplexed streams over a single connection can drastically reduce latency and resource usage.

Performance and Memory: The Raw Numbers

The pydantic team hasn’t just refactored for aesthetics; they’ve delivered hard performance gains. Early benchmarks from the repository show a 30–50% reduction in overhead per request compared to httpx 0.27.x under high concurrency. Memory usage is also significantly lower because the new connection pool implementation avoids creating duplicate objects for synchronous wrappers.

For an engineer building a review sentiment dashboard from scraped G2 and Trustpilot data, this translates directly into lower cloud compute costs. If your scraper is making 100,000 requests per hour, a 40% reduction in per-request CPU time means you can either process more data on the same instance or downsize your fleet.

API Compatibility: The Clean Break

Here is where you need to pay attention. HTTPX2 is not a drop-in replacement for httpx. The maintainers made the deliberate decision to break the API where it was inconsistent or confusing. The import path changes from import httpx to import httpx2. Common patterns like httpx.get() will still work for simple scripts, but anything touching the client internals, custom transports, or middleware will need rewriting.

This is a classic "clean break" strategy. The team is avoiding the trap of carrying forward a decade of accumulated API quirks. For engineers who maintain internal libraries that wrap httpx, you should budget time to fork your code or pin your dependencies until you can migrate.

How to Try HTTPX2 Today

HTTPX2 is in active development, but you can install the pre-release directly from the repository:

pip install git+https://github.com/pydantic/httpx2.git

Start with a simple async script to feel the new structure:

import asyncio
import httpx2

async def main():
    async with httpx2.AsyncClient() as client:
        response = await client.get("https://httpbin.org/json")
        print(response.json())

asyncio.run(main())

If you are prototyping an agent that needs to make rapid sequential API calls—for example, a resume tailoring agent using Groq and Llama 3—the new client’s connection reuse and lower latency will make your feedback loops noticeably faster.

The Balanced Take: Is It Ready for Production?

As of mid-2025, HTTPX2 is pre-1.0. The core HTTP/1.1 and HTTP/2 functionality is solid, but the ecosystem of third-party plugins and transports hasn’t caught up yet. If you rely on httpx for a mission-critical production service, you should pin your httpx version and start testing HTTPX2 in a staging environment. The original httpx will continue to receive security patches, but new features are frozen.

The migration path is not painless, but the long-term payoff is real. A unified async core eliminates entire categories of concurrency bugs. For FDEs who often operate as the bridge between a customer’s immediate needs and the product’s future direction, this is exactly the kind of technical shift you need to track. Your ability to advise a customer on whether to upgrade their internal tooling is part of what an FDE actually does in a week.

FAQ

Is httpx dead?

No, but it is in maintenance mode. The original httpx will receive bug fixes and security updates, but all active feature development is happening in HTTPX2.

Can I use HTTPX2 with FastAPI or Starlette?

Not as a drop-in test client yet. FastAPI’s TestClient is built on httpx. The ecosystem needs to adapt to the new httpx2 API before seamless integration is possible.

Does HTTPX2 support SOCKS proxies?

The rewrite simplifies the transport layer. Built-in SOCKS support is not in the core yet, but the new transport API is designed to make third-party transports easier to write and maintain.

How does this compare to aiohttp?

aiohttp is async-only and has its own server framework. HTTPX2 provides both sync and async APIs from a single codebase, which is a significant advantage for scripts and tools that need to run in both contexts without code changes.

What’s the minimum Python version?

HTTPX2 targets Python 3.9+ and leverages modern asyncio features, including the newer TaskGroup patterns where appropriate.