Two sequential RubyLLM.judge calls using the async_http adapter. The script records completed TLS handshakes and prints them after each call. It uses real requests to the TypeSafe Jev API, without HTTP mocks or an application-managed Async reactor.
Save Gemfile and probe.rb in one directory. With TYPESAFE_API_KEY set in your environment, run:
bundle install
bundle exec ruby probe.rbThe script sends two small, billable API requests. It reads the key from the environment and does not print it. RubyLLM retries are disabled.
The second call should be able to reuse the connection from the first call. In the tested version, each call completes a new TLS handshake on a different socket. The summary is:
Total: 2 calls, 2 TLS handshakes
ALPN="h2" means HTTP/2 was negotiated. session_reused=false means the TLS session was not resumed. TLS session resumption, if reported, would still be a handshake on a new connection, not reuse of the existing connection.
The model's answer to the keep-alive question is just an Easter egg. The handshake records are the evidence of connection setup. The probe does not measure a latency improvement.
- Ruby 4.0.6
- RubyLLM commit
f7fd97d14b65c546d49606f91f97c3fdcf82f64b - Faraday 2.14.4
- async-http-faraday 0.24.0
- async-http 0.105.0
- Async 2.46.0
- OpenSSL gem 4.0.2
The Gemfile pins RubyLLM and the adapter. Other dependencies may resolve to newer versions.
See output.txt for a run on the reporter's computer on 2026-09-27. The Ruby IO::Buffer experimental warning was omitted.
Times use a monotonic clock. Call duration covers the full RubyLLM.judge call. TLS handshake covers elapsed time from the first SSL connect attempt to handshake completion, including waits. It excludes DNS lookup and TCP connection setup. The TLS time is part of the call duration, not an additional duration to add to it.
This sample shows two new TLS handshakes. It does not compare against connection reuse or establish how much faster a pooled implementation would be.