httpx2: a maintained HTTPX continuation for Python, with a CLI and sync/async APIs

The problem httpx2 solves is maintenance, not features

HTTPX is one of the libraries Python services quietly depend on. The httpx2 README is explicit about why the fork exists: HTTPX itself is described as having seen limited activity recently, and Pydantic is picking up stewardship so that users have a reliably maintained path forward, including timely security updates for a library that sits in the critical path of many production systems. That is the whole pitch. There is no new protocol, no rewritten transport, no API break announced in the README. The audience is teams who already ship HTTPX and want a maintainer who responds when a CVE lands in a dependency, not teams shopping for a better HTTP client. If you are starting a new project today and have no HTTPX code to preserve, the decision is closer to a coin flip than the README admits: the feature list is inherited, so the differentiator is release cadence and who is holding the keys.

What is actually inside: transports, clients, and the httpcore2 split

The architecture is the same shape HTTPX users know. httpx2 is the client layer; httpcore2 is the transport implementation underneath it, and both live in the same repository as uv workspace members under src/httpx2 and src/httpcore2. On top of the transport sit the two client classes, httpx2.Client and httpx2.AsyncClient, which the README says are instrumented the same way as top-level calls. HTTP/1.1 comes from h11. HTTP/2 comes from h2 and is optional. anyio supplies the structured concurrency primitives that let the async client run on either asyncio or trio rather than being welded to one event loop. truststore handles SSL verification against the operating system trust store instead of a bundled certificate list, and idna covers internationalized domain names. Two details in the repository layout are worth noting because they are unusual for a client library. First, there is a benchmark/ directory and a bench dependency group containing aiohttp and pyinstrument, so the project measures itself against another client rather than only against its own history. Second, pyproject.toml sets exclude-newer = "7 days" for uv, which means the development environment refuses dependency versions published in the last week. That is a supply-chain hygiene choice, and it also means contributors occasionally wait a week for a fix to become installable.

Installing httpx2 and making a first request

The README gives pip as the install path. The base package is enough for HTTP/1.1, sync and async clients, and the requests-compatible API.

pip install httpx2

The README then shows a session in which a module-level call returns a response whose status_code, headers and text you can read directly.

import httpx2

r = httpx2.get('https://www.example.org/')

r.status_code
r.headers['content-type']
r.text

The reader should see 200 from status_code, a content-type header such as 'text/html; charset=UTF-8', and then the page body. The command line client is a separate install, because the README calls it an optional dependency:

pip install 'httpx2[cli]'
httpx2 --help

HTTP/2 is also opt-in rather than automatic. If you need it, install the extra, because the base package pulls h11 only:

pip install httpx2[http2]

The same pattern applies to socks, brotli and zstd. Nothing in the README suggests these are enabled by default, and the dependency list marks each one as optional with its own extra.

Optional extras are the first thing that breaks

The extras design is the most likely source of surprise. A service that upgrades from a working HTTPX deployment to httpx2 and calls an HTTPS endpoint through a SOCKS proxy will fail unless socksio is present, because SOCKS support lives behind httpx2[socks]. A service that expects brotli-compressed responses to decode will get raw bytes unless brotli or brotlicffi is installed via httpx2[brotli]. The zstd case is the sharpest edge in the README: on Python 3.13 and below, decoding zstd responses requires backports.zstd through httpx2[zstd], while on Python 3.14 and above the standard library compression.zstd module is used when available, and the extra installs nothing. So the same requirements file behaves differently depending on the interpreter version, and on 3.14 the extra is a no-op that can mask a missing capability if you assume installing it did something. Pin your extras per interpreter, or install the full set the dev group uses: httpx2[brotli,cli,http2,socks,ws,zstd].

httpx vs httpx2: a fork, not a rewrite

The honest comparison is against HTTPX itself, and the README frames it as a continuation rather than a competitor. The API layout is deliberately requests-compatible, and the README credits requests for that layout and urllib3 for design inspiration around lower-level networking. What differs is the package name, the import name, the dependency on httpcore2 rather than httpcore, and the release cadence: v2.11.0 and v2.12.0 both landed on 2026-08-18, and v2.13.0 on 2026-09-14. If you are weighing a switch, the practical question is not which library is better but how much of your stack names httpx explicitly. Test fixtures, pytest plugins, instrumentation hooks and import-time monkeypatches that target httpx will not see httpx2 unless they are updated, and the README does not claim drop-in import compatibility. It describes httpx2 as broadly requests-compatible, which is a statement about the requests API surface, not about substituting for httpx in existing code. For a greenfield service the difference is mostly the name on the import line. For a large existing codebase, it is a migration with a real inventory step.

Observability, licensing, and what an upgrade costs

Instrumentation is where the Pydantic ownership shows. The README documents a one-line setup using Logfire, Pydantic's OpenTelemetry-based platform: configure it, call logfire.instrument_httpx(), and every request is traced with timings and status codes. The same call works for explicit httpx2.Client() and httpx2.AsyncClient() instances, and passing a client in scopes instrumentation to that one object; capture_all=True additionally records headers and bodies. That last option deserves a second look before you enable it in production, since headers routinely carry credentials. The README does not describe an equivalent first-party instrumentation path for other OpenTelemetry setups, so if you are not on Logfire, budget time to check what your existing HTTPX instrumentation does when the module name changes. On licensing, the repository ships LICENSE.md and the README states the code is BSD licensed; the project page identifies it as BSD-3-Clause. That is permissive and compatible with commercial use, but this is a description of the licence file, not legal advice, and you should read LICENSE.md yourself before relying on it. Upgrade cost is otherwise low: the package is versioned in the 2.x line and the releases above are minor bumps, so the README gives no indication of a breaking change between them. It also does not document a rollback procedure, and there is no deprecation policy stated in the README.

Editorial conclusion

Adopt httpx2 if you already depend on HTTPX and want a package whose last push was on 2026-09-17 and whose releases ship on a monthly cadence. Stay on the original if your tooling pins entry points or module names that the fork changes. Before you commit, verify three things: that `import httpx2` resolves in your environment, that every optional extra you need (http2, socks, cli, brotli, zstd) is installed explicitly, and that any library which patches or instruments HTTPX has a documented path for httpx2.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. pydantic/httpx2 on GitHub
4. README
5. Releases