Loading post…
Hugging Faceshaun smith, ben burtenshaw, merve, Pedro CuencaAnnouncement
Open Responses: What you need to know
Summary
Open Responses is a new open inference standard initiated by OpenAI, developed by the open source AI community, and backed by Hugging Face. While agentic workloads require multi-step planning and tool execution, the ecosystem has remained constrained by the legacy Chat Completion format and proprietary Responses implementations. Open Responses addresses this mismatch by standardizing semantic event streaming, provider-specific configuration options, and distinct roles for model providers and intermediary routers. The specification formalizes reasoning visibility across raw traces, protected encrypted content, and sanitized summaries while supporting provider-managed sub-agent execution loops. Developers can now orchestrate multi-step tool calls and stream reasoning deltas across heterogeneous providers through a single consistent API schema.
Context
Autonomous AI agents require systems that reason, plan, and act over long time horizons, but much of the inference ecosystem still relies on the legacy Chat Completion format designed for turn-based conversation. Although the Responses API format was designed to solve these agentic limitations, its closed nature hindered broad adoption and cross-provider standardization.
Approach / What changed
Open Responses open-sources and extends the Responses API into a shared standard featuring stateless operations, semantic event streaming, standardized model configurations, and separated definitions for Model Providers and Routers. It formalizes raw reasoning, encrypted reasoning, and summary streams, while natively handling internally and externally executed tool-calling loops on the provider side.
Takeaways
Open Responses formalizes three reasoning item fields: content for raw reasoning traces, encrypted_content for protected content, and summary for sanitized traces.
The standard natively supports both internally hosted tools executed entirely within the provider infrastructure and externally hosted tools like client functions or MCP servers.
Provider-managed sub-agent loops enable multi-step reasoning and tool execution cycles in a single request, controlled by max_tool_calls and tool_choice parameters.
Source and freshness
- Source
- huggingface.co
- Published
- Added to Yomu
- Last updated
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.