chat-responses
Generic OpenAI Responses API wire client for chat-rs. Symmetric counterpart to chat-completions: owns the /responses endpoint wire types and SSE stream parsing. Point it at any server implementing the Responses API.
Install
[]
= "0.2.2"
= "0.1.1"
= { = "1", = ["macros", "rt-multi-thread"] }
Or via the umbrella crate: chat-rs = { version = "0.3.1", features = ["responses"] }.
Usage
use ResponsesBuilder;
use ;
let client = new
.with_base_url
.with_model
.with_api_key
.build;
let mut chat = new.with_model.build;
let mut msgs = from_user;
let response = chat.complete.await?;
Capabilities
- Completions — text generation with tool calling and structured output
- Streaming — SSE token streaming (requires
streamfeature) - Reasoning effort —
.with_reasoning_effort("medium")for reasoning models - Previous-response-id round-tripping — server-side context resume (default on)
- Custom tool declarations —
.with_tool_declaration(value)for wrappers that want to inject provider-specific tools as raw JSON
When to Use This vs chat-openai
Use chat-responses directly when you control the endpoint or are wrapping a Responses-API provider that isn't OpenAI. Use chat-openai when you want the OpenAI defaults (URL + OPENAI_API_KEY), the OpenAI-specific native tools (web_search, image_generation), and the /embeddings endpoint.
Decoupled Native Tools
The wire layer is trait-agnostic. Wrappers materialize their provider-specific native tools into serde_json::Value and pass them via .with_tool_declaration():
let client = new
.with_base_url
.with_model
.with_api_key
.with_tool_declaration
.build;
Custom Transport
Pluggable via .with_transport(). Defaults to HTTP/SSE via reqwest. WebSocket transports (AsyncWsTransport, WsTransport) work when paired with a Responses-API WS endpoint.
Feature Flags
Streaming is gated on the stream feature:
= { = "0.1.1", = ["stream"] }