rig-reqwest

The bundled reqwest HTTP transport for Rig: ReqwestClient and ReqwestMiddlewareClient implement HttpClientExt. It depends only on rig-http, which holds that contract. ReqwestClient::default() is the process-wide client, built once on first use and shared by every clone; ReqwestClient::from(client) wraps a host-built reqwest::Client. With rig-core's reqwest feature (on in the rig facade), a provider client built with no transport named, such as OpenAI::from_env()?, sends through ReqwestClient::default(); any other client goes in with .with_http(client). Construction never fails: when the reqwest client cannot be built, every send reports the build failure in-band.

rig-core without its reqwest feature has no reqwest/Tokio dependency; this crate is where both live. On native targets, requests and lazy response bodies capture the caller's Tokio context or, outside Tokio (Bevy task pools, smol, futures::executor), a lazily started fallback reactor. Each poll enters that context; no detached per-request or stream-forwarding worker owns the operation. Dropping a request, response body or stream releases its local operation without waiting for another upstream chunk. It cannot undo a remotely accepted request.

A host runtime must enable I/O and timers and remain driven. Context detection does not prove this; a runtime without its reactor can panic during I/O. A handle alone does not keep a runtime alive. Stop admitting work, cancel/drain owned operations, release shared clients, then shut down the runtime. Supplied endpoint, proxy, redirect, TLS and timeout policy remains with the host-built client. WASM uses its native browser transport path, not the native Tokio fallback.