11–20 of 35 posts
Earlier quoted context omitted.
Is this true? I can click open o3’s dialogue and see a running monologue. I guess it might be a summary of the actual reasoning though.
Correct, you are not seeing the reasoning chains.
> Encrypted reasoning items: Customers eligible for Zero Data Retention (ZDR) can now reuse reasoning items across API requests So, so weird that they still don't want you to see their models' reasoning process, to the point that even highly trusted organizations with ZDR contracts only get them in a black-box encrypted form. Gemini has no issue showing its work. Why can't OpenAI?
The customer service itself was surreal enough that it was easier just to migrate to Anthropic
> Encrypted reasoning items: Customers eligible for Zero Data Retention (ZDR) can now reuse reasoning items across API requests So, so weird that they still don't want you to see their models' reasoning process, to the point that even highly trusted organizations with ZDR contracts only get them in a black-box encrypted form. Gemini has no issue showing its work. Why can't OpenAI?
It's not weird at all. R1-distills have shown that you can get pretty close to the real thing with post-training on enough completions. I believe gemini has also stopped showing the thinking steps (apparently the GLM series of open access models were heavily trained on gemini data).
ToS violations can't be enforced in any effective way, and certainly not cross-borders. Their only way to maintain whatever moat thinking models give them is to simply not show the thinking parts.
It was never really clear what the difference between the chat and responses APIs were. Anyone know the difference?
responses api, by contrast, is stateful — only send the latest message, and openai stores the conversation history, while keeping track of other details on behalf of the calling app, like parallel tool call states.
but i would say that since chat completions has become an informal industry standard, the responses api feels like an attempt by openai to break away from that shared interface, because it is so easy to swap out providers with nothing more than a base url and a model id, to a paradigm which requires data migration as well as replacement infrastructure (containers for code execution, for example).
> Encrypted reasoning items: Customers eligible for Zero Data Retention (ZDR) can now reuse reasoning items across API requests So, so weird that they still don't want you to see their models' reasoning process, to the point that even highly trusted organizations with ZDR contracts only get them in a black-box encrypted form. Gemini has no issue showing its work. Why can't OpenAI?
And yes, the above is true even if you are ULTRA.
You can still view your old thinking traces from prior turns and conversations.
Earlier quoted context omitted.
Correct, you are not seeing the reasoning chains.
I may be giving Gemini too much credit, actually - seems like its "reasoning" may be a summary as well.
I wish OpenAI would provide more clarity about the Assistants API deprecation, which has been announced as being sunset in spring of 2026 and replaced by the Responses API, but still no other updates on the timeline or migration plan. Prior to the release of the Responses API, the Assistants API was the best way (for our use cases, at least) to interact with OpenAI's API, so hopefully some clarity on the plan for it…
We're almost ready to share a migration guide. Today, we closed the gap between Assistants and Responses by launching Code Interpreter and support for multiple vector stores in File Search.
We still need to add support for Assistants and Threads objects to Responses before we can give devs a simple migration path. Working on this actively and hope to have all of this out in the coming weeks.
It was never really clear what the difference between the chat and responses APIs were. Anyone know the difference?
chat completions is stateless — you must provide the entire conversation history with each new message; openai stores nothing (at least nothing that the downstream product _can use_) beyond the life of the request. responses api, by contrast, is stateful — only send the latest message, and openai stores the conversation history, while keeping track of other details on behalf of the calling app, like parallel tool cal…
for example, you can give the responses api access to 3 tools: a vector store with some user memories (file_search), the shopify mcp server, and code_interpreter. you can then ask it to look up some user memories, find relevant items in the shopify mcp store, and then download them into a csv file. all of this can be done in a single api call that involves multiple model turns and tool calls.
p.s. - you can also use responses statelessly by setting store=false.
Im quite surprised they’re actually going with hosted mcp versus just implementing the mcp server locally and interacting with the api
responses api is a hosted thing and so it made most sense for it to directly connect to other hosted services (like remote mcp servers).
I wish OpenAI would provide more clarity about the Assistants API deprecation, which has been announced as being sunset in spring of 2026 and replaced by the Responses API, but still no other updates on the timeline or migration plan. Prior to the release of the Responses API, the Assistants API was the best way (for our use cases, at least) to interact with OpenAI's API, so hopefully some clarity on the plan for it…
I hear you and really appreciate the patience here. We're almost ready to share a migration guide. Today, we closed the gap between Assistants and Responses by launching Code Interpreter and support for multiple vector stores in File Search. We still need to add support for Assistants and Threads objects to Responses before we can give devs a simple migration path. Working on this actively and hope to have all of thi…
I started my MVP product with assistants and migrated to responses pretty easily. I handle a few more things myself but other than that it's not really been difficult.