Automatic Key Exchange just cut HelloRetryRequests from 52% to 3.

TLS 1.3 is supposed to be fast, but there is a hidden performance tax when a client guesses the wrong key agreement algorithm. In a standard handshake, the client has to commit to a key share in the first packet. If the server doesn't support that specific algorithm, it fires back a HelloRetryRequest (HRR), forcing the client to start over. This effectively doubles the round-trip time. For a massive proxy like Cloudflare, guessing X25519 for every single origin was resulting in a 30% failure rate on that first guess.

The fix is a measurement-based approach called Automatic Key Exchange. Instead of blindly guessing, the system now probes origins to see what they actually prefer. The real win here isn't just the latency—which saw p90 handshake times drop by over 150ms—but the silent rollout of post-quantum cryptography. By leading with X25519MLKEM768 whenever the origin supports it, they are mitigating "harvest-now, decrypt-later" attacks without requiring the site owner to manually toggle a switch in a dashboard.

How the handshake logic shifted

In the old workflow, the sequence looked like this:
1. Client sends ClientHello with an X25519 keyshare.
2. Origin (if it doesn't like X25519) sends HelloRetryRequest.
3. Client sends a second ClientHello with the requested algorithm.
4. Connection finally establishes (2 round trips).

With Automatic Key Exchange, the logic moves to a stateful measurement:
1. System probes origin and records supported algorithms.
2. Client sends ClientHello with the known preferred keyshare (e.g., X25519MLKEM768).
3. Origin accepts immediately.
4. Connection establishes (1 round trip).

Implementing a similar "Probing" logic in an AI workflow

If you are building an LLM agent or a custom AI workflow that interacts with various third-party APIs, you can apply this same "probe-and-cache" logic to avoid repeated errors or "retry" latencies. Instead of sending a generic request and handling an error, you can implement a lightweight handshake to determine the target's capabilities first.

Here is a practical tutorial on how I'd structure a prompt to generate a "Capability Probe" logic for a Python-based agent. I use a specific system prompt to ensure the AI doesn't just give me a basic loop, but actually implements a caching layer to mimic the "Automatic Key Exchange" behavior.

Act as a Senior Backend Engineer. Design a Python class called `CapabilityManager` that implements a "probe-and-cache" strategy for API interactions. 

The logic must follow these requirements:
1. Maintain a local cache of `origin_id` to `supported_feature` mappings.
2. Before making a primary request, check the cache.
3. If the feature is unknown, perform a lightweight 'OPTIONS' or 'HEAD' request to the endpoint to detect capabilities.
4. Cache the result for 24 hours to avoid repeated probe latency.
5. If the probe fails or the feature is unsupported, fallback to a 'safe' default mode.

Provide the implementation using `httpx` for asynchronous requests and `pydantic` for the cache schema.

Why this approach works

The beauty of this pattern is that it shifts the cost of discovery from the "critical path" (the actual user request) to a "background path" (the probe). In the context of the 45 billion daily connections mentioned, reducing the HRR rate from 52% to 3.7% is a massive win for global tail latency.

For those of us doing prompt engineering or building agents, the takeaway is clear: don't rely on "guessing" the state of your external tools or LLM versions. Build a discovery layer that remembers what the target can actually do, and you'll stop hitting those expensive "retry" loops that kill your application's perceived speed.