The two response payloads in the guide differ by one field. A thread comes back with `tool_resources`, empty in the example; the conversation comes back with id, object, created_at and metadata, and nothing else [12]. At the create site the diff is shallow too: `openai.beta.threads.create` takes `messages`, `openai.conversations.create` takes `items`, and the metadata dict is unchanged [20]. That is the easy half, and it is the half the code samples cover.
The run is where the work is. A run was an asynchronous process executed against a thread, and the guide's own Python example sits in a while loop on `run.status`, sleeping one second between retrievals [13]. That is roughly one retrieval per second of run duration [18]. A response returns its output items from the call [2], so the polling loop goes away. What arrives in its place is a loop you design: the guide lists history pruning, the tool loop and retries as orchestration handled by application code, with the prompt left to carry system guidance, tool availability, structured output schema and temperature defaults [7]. You trade a loop you could copy out of the docs for one you have to get right.
Then there is where prompts live. An assistant bundled model choice, instructions and tool declarations, and you created and managed it entirely through the API [4]. A prompt can only be created in the dashboard [5]. Step three of the migration steps says to store the prompt ID, or its exported spec, in source control so code can refer to a stable identifier [9]. The identifier is what your repo pins; the authoring surface is a UI. Snapshot, review, diff and rollback on prompt specs [6] are a real gain over a server object whose current state was whatever your last API write left, and A/B testing by swapping prompt IDs is cheaper than creating and deleting assistant objects programmatically [10]. The bill lands if your assistants were per tenant. Migrating N instruction bundles is N dashboard actions [19], and nothing in this guide restores the programmatic path.
The guide also claims better performance and names deep research, MCP and computer use as new features [2], with no numbers in the text [17]. For the performance half to reach your p95, your latency would have to have been dominated by run polling rather than model time; if your median run spent several seconds inside the model, one-second poll granularity was noise, and the gain here is a simpler call shape. Responses is designed to be used alone, with prompt and conversation objects optional for storing context and configuration [14]. That is the escape hatch: keep your own transcript store, and the dashboard prompt becomes the only part of your behaviour spec that CI cannot author. The guide already writes about assistants, threads and runs in the past tense [15].
In my context one manual dashboard step per product surface is an acceptable trade, because we ship one behaviour bundle per surface and want the diff history more than we want the API call. If yours are minted per customer at signup, this is a design change, and it should be budgeted as one.
