mirror of
https://github.com/pchuan98/codex.git
synced 2026-07-01 00:31:56 +08:00
jif
baddb5e686
## Why Responses WebSocket requests were encoded in two steps: first into a full `serde_json::Value`, then again into the JSON string sent over the socket. That walks the full request twice and keeps an extra JSON tree alive. These requests can contain the complete conversation history and tool schemas, so the extra work grows with the request size. ## What changed - serialize `ResponsesWsRequest` directly to the wire string - pass that string through the existing WebSocket stream and send path - keep the existing error mapping, tracing, send timeout, and telemetry behavior - compare the new wire JSON with the previous `to_value` payload in a focused test ## Performance I measured both paths in an optimized temporary test using a 6,324,180-byte request: 4 MiB of history plus 256 tools with 8 KiB descriptions. Each path ran 100 times. - previous `to_value` + `to_string`: 209 ms total, 2.09 ms per request - direct `to_string`: 174 ms total, 1.74 ms per request - difference: about 17% faster, or 0.35 ms per request The direct path also removes one full temporary `serde_json::Value` tree. For this mostly string-backed payload, that avoids roughly one payload-sized copy plus the JSON node overhead. The exact memory saving depends on the request shape. The temporary benchmark was removed before committing. ## Validation - `just test -p codex-api` — 125 passed - `just fix -p codex-api`
baddb5e686
·
2026-06-15 18:33:35 +02:00
History
codex-api
Typed clients for Codex/OpenAI APIs built on top of the generic transport in codex-client.
- Hosts the request/response models and request builders for Responses and Compact APIs.
- Owns provider configuration (base URLs, headers, query params), auth header injection, retry tuning, and stream idle settings.
- Parses SSE streams into
ResponseEvent/ResponseStream, including rate-limit snapshots and API-specific error mapping. - Serves as the wire-level layer consumed by
codex-core; higher layers handle auth refresh and business logic.
Core interface
The public interface of this crate is intentionally small and uniform:
-
Responses endpoint
- Input:
ResponsesApiRequestfor the request body (model,instructions,input,tools,parallel_tool_calls, reasoning/text controls).ResponsesOptionsfor transport/header concerns (conversation_id,session_source,extra_headers,compression,turn_state).
- Output: a
ResponseStreamofResponseEvent(both re-exported fromcommon).
- Input:
-
Compaction endpoint
- Input:
CompactionInput<'a>(re-exported ascodex_api::CompactionInput):model: &str.input: &[ResponseItem]– history to compact.instructions: &str– fully-resolved compaction instructions.
- Output:
Vec<ResponseItem>. CompactClient::compact_input(&CompactionInput, extra_headers)wraps the JSON encoding and retry/telemetry wiring.
- Input:
-
Memory summarize endpoint
- Input:
MemorySummarizeInput(re-exported ascodex_api::MemorySummarizeInput):model: String.raw_memories: Vec<RawMemory>(serialized astracesfor wire compatibility).RawMemoryincludesid,metadata.source_path, and normalizeditems.
reasoning: Option<Reasoning>.
- Output:
Vec<MemorySummarizeOutput>. MemoriesClient::summarize_input(&MemorySummarizeInput, extra_headers)wraps JSON encoding and retry/telemetry wiring.
- Input:
All HTTP details (URLs, headers, retry/backoff policies, SSE framing) are encapsulated in codex-api and codex-client. Callers construct prompts/inputs using protocol types and work with typed streams of ResponseEvent or compacted ResponseItem values.