Introducing the Responses API

Announcements
1

We’re making improvements to how you build assistants and use tools with the OpenAI API. Based on your feedback from the Assistants API beta, we’ve built the Responses API — a faster, more flexible, and easier way to create agentic experiences that combines the simplicity of Chat Completions with the tool use and state management of the Assistants API. To start, the Responses API will support new built-in tools like web search, file search, and computer use. You can read more about Responses and these new tools in our blog post.

Here’s what this means for the Assistants API:

  • Feature parity between Responses and Assistants: We’re working on bringing key Assistants API features — like support for Assistant-like and Thread-like objects, plus the Code Interpreter tool — into the Responses API.
  • Deprecation timeline: Once parity is reached, we will announce the deprecation of the Assistants API in the first half of 2026 with 12 months of support from the deprecation date so you have ample time to migrate.
  • Migration support: When we announce the deprecation date, we’ll also provide a comprehensive migration guide to help you move smoothly to Responses, with full data preservation.
  • No immediate changes: The Assistants API will continue to be supported in the near term, and we’ll continue to add new models to it. We’re planning deprecation in 2026, but we’ll follow up again to give you notice of the full plan.

You can get started in our docs. I’m excited to see what you build with these new APIs and tools, and please don’t hesitate to reach out here if you run into any questions.

8 Likes
3

I’m in the early stages of building a chat-focused app using the Assistants API. Would it make sense to jump to Responses now or continue on this path and wait for the migration?

1 Like
4

I’m in the same situation and would love an honest opinion on this. Should I stick with the Assistants API for now or switch to Responses ahead of the migration?

5

Does it work with the Batch API?

6

@ben.mcgee.good switching at this time to Responses API would make sense, alternately using chatCompletions API to familiarize yourself with building and then migrating to Responses API.

7

so that’s why assistant api was in beta all the time.

1 Like
8

Assistants API is slow too

9

OMG - so SLOOOOOW. Hope the reponsesAPI is faster

10

If I’m not wrong. Responses API does not yet have the features that you would want in the assistance API like the threads so for people building chat like interfaces you still can rely on assistants API.

11

Seems responses is the way to go. But migrating should not be that hard either.

12

The responses API doesn’t have threads, a single list of messages and internal calls that you can add to and run.

Instead, for server-side chat history state, it stores the request ID and its completion contents with every API call you make.

There is also an API parameter for “instructions” if you want the first system message to be separately changeable instead of being a part of the past messages sent.

To use this, (in the manner that many novices would expect API calls to somehow “remember” exactly who they are), you take the most recent response’s ID and send it back as the parameter for previous_response_id. When you do that, the past chat and responses you specify is reused, and you only need the newest user role question as a message in input.

There is still no cost management: the chat length will grow to the model maximum, where it will return an error, or you can set truncation:auto to start deleting old messages at the model’s maximum input.