What we win:
Nothing, the new way is doable right now.
What we loose:
A lot of speed, right now we can iterate faster on prompts in the playground. Just get a prompt that is not working and iterate over it without needing to touch the code.
Welcome back, @Gustavo_Stefani …
I still use the playground quite a bit personally.
Everything is changing so fast these days… I still miss text-davinci-003 personally. 
This is terrible I have a lot of web apps based on prompt objects, is super convenient cause I can make small fixes to the prompt without redeploying, and also rollback to previous versions. I don’t understand what’s the reason behind this, it’s actually an efficient “vendor lock” they have in place. I hope they reconsider
agreed- the main advantage of stored prompts is application independent, rapid prompt development, model optimizations and hotfixing. Migrating prompts to the projects codebase won’t help with either of these.
Totally agree.
My customers will probably start asking me to move to a more stable AI provider since OpenAI very frequently forces us to migrate/change to other ways of doing things.
The migration from Assistants API to Responses API was full of benefits, and I got that. But this does not have any benefit that I can see and actually is a step back in many aspects and makes it more difficult for non-programmer users to maintain and evolve chatbot and AI automation solutions.
Yes and this is not a transition they are just removing a useful feature without a replacement. The “migration guide” is like “put this back into your code and good luck”. Not a good sign honestly
Does this mean that the “Chat” prompt menu and functionality within OpenAI API Dashboard will now be deprecated?
I use this functionality in all of my projects, and if the deprecation notice is true, requires changing many, many projects, and hence receiving less functionality and adaptability.
I trust OpenAI will reconsider this deprecation notification.
IMHO: Nothing lost.
An attempt to force you into a UI to make a prompt as a reusable undiscoverable incomplete request shape that requires knowledge of it for success anyway.
Developed as playground-UI-only simply to increase the friction of simulating a “GPT” for a user on demand?
How to use the API like a normal person:
Maybe now: turn back on the Playground Chat Completions presets, which were locked from editing and creating, now pinned to shutoff models, as a scheme to force-promote “prompts”.
Is our stored prompt will be gone? where do you guys save the template?
If you really want back out what you put in, you can use a browser’s web developer tools → network, and monitor the requests and responses to the API URL that services the web page of “chat” when you switch between prompts (preset settings) and the values are pushed to the UI.
Another internal API gated to Oauth2->session token and browser signature - where API access could have made the system a bit more useful.
Whats the point of separate projects in the openai UI Dashboard? No agent builder, no chat prompts, … there doesnt seem to be any reasons to have a dashboard.
Assistants were great but OpenAI forced API users to transition to Prompts.
Now they’re taking away the Prompts. It’s very frustrating and it will take even more work to keep things running.
The concern for me is that for my use case, the instructions for processing an input are as large or larger than the input itself. Whereas with Assistants and Prompts I did not have to explicitly provide the instructions to the model, only had to provide the input text, with Chats if I have to create a new chat for each input and provide those instructions to each chat, the cost will skyrocket. I’ll have to figure out if I can use one chat for multiple completely unrelated inputs.
Yeah, I’ve lived through the migrations from Assistants to Prompts to now aswell. Frustrating!
Good points regarding the prompts - The “large” instructions will now be passed to the Responses API from our code, which will add lots more content from the API call, originating within our web app or mobile device.
The major disadvantage I see is that, unless the instructions are placed within a database, any minor change to the prompt will require a rebuild and redeploy - the prompts allowed for great flexibility, which I often used.
At least give us enough time to migrate from feature A to B, before deprecating B as well. I wasn’t even finished with the migration from Assistants to Prompts 
The costs will not skyrocket.
There is some misunderstanding here: The prompts feature is simply a way for you to have provided the same input to the AI model, but stored on the OpenAI servers.
You paid for the input data of a large instructions field in the model’s input cost regardless of whether it was added by use of a prompt’s “developer” message created in the platform site (no longer “playground” because prompts and the UI now is not fun), via the “instructions” field in the Responses API, or whether by self-managed chat turns with a “system” role message as guidance.
The only thing this feature might have saved you is some in-flight network time - but OpenAI’s backend services, and even Responses vs Chat Completions, add latency also. And models now have thinking a long time before you see any output as a latency feature.
Calls to the API should not be originating from mobile devices, calling OpenAI directly, that you have to “redeploy”. That indicates that your client code has the API key. You just gave every user the password to make their own API calls, only needing to be captured over the network or reversed out of the app.
@_j - please confirm that you’re saying that with Prompts I’m paying for the tokens required by the instructions each time a Response is created that references a Prompt? In my tests using the Chat Prompts playground this does not appear to be the case.
One factor that will mitigate the cost associated with sending the instructions over and over is a feature called “Prompt Caching” which will reduce the token cost impact of sending the same instructions over and over. Prompt caching | OpenAI API
Let’s API test to show this does appear to be the case, and cannot be anything else.
Here’s what is sent by an API call from the Responses API “chat” (Playground) when you use a saved prompt with no alterations, the request captured from a browser’s developer tools:
{
"input": [
{
"role": "user",
"content": [{"type": "input_text", "text": "Ping? Ready to prompt?"}],
}
],
"text": {"format": {"type": "text"}},
"reasoning": {},
"stream": true,
"max_output_tokens": 2048,
"store": true,
"include": ["web_search_call.action.sources"],
"prompt": {
"id": "pmpt_68509ee68835b7602781fba6f8de760810819e3ec6bb2f8b",
"version": "2",
},
}
How many tokens of text do you see? There’s four words.
Your bill at the bottom of the Playground “840t” input:
Your usage object from the response.output_item.done event:
"usage": {
"input_tokens": 840,
"input_tokens_details": {"cached_tokens": 0},
"output_tokens": 40,
"output_tokens_details": {"reasoning_tokens": 0},
"total_tokens": 880,
},
Result: 823 tokens of text in the prompt ID successfully billed to you.
What is a prompt ID anyway? I pulled out all of its non-API fields, and here is the shape you are left with:
prompt = {
"instructions": [
{
"type": "message",
"content": [
{
"type": "input_text",
"text": 'You are an expert-level **AI..(blah blah x 820)..',
}
],
"role": "system",
}
],
"model": "gpt-4.1",
"reasoning": {"effort": null},
"temperature": 0.8,
"text": {"format": {"type": "text"}},
"tool_choice": "auto",
"tools": [],
"top_p": 0.5,
}
Simply the same parameters you put in an API call. But here, don’t forget what tools you have turned on, or you might not send the required extra parameters or might not request the extra “include” objects to make use of them, besides not handling your functions you forgot about - and you can’t retrieve a prompt ID over the API either.
@_j - confirmed. Thank you. I think in my previous test I received a tiny token cost on my message because it wasn’t the first message in the thread.
The playground-iteration loss is real, but there’s a pattern that keeps most of the speed: store prompts in your own DB/config with a tiny admin page (or even a Google Sheet your code reads), version them yourself, and A/B in production with the Responses API. You lose the playground UI but gain versioning + diffability, which dashboard Prompts never gave anyway.
The bigger reason to start now rather than at the deadline: anyone currently migrating off the Assistants API (dies Aug 26) following older guides is being pointed toward Prompt Objects — which now also die Nov 30. Worth flagging in any migration plan so people don’t pay for two migrations.
I am curious as to WHY Openai decided to deprecate the prompt object (prompt id), when it was such as useful tool. Could someone from Openai provide a real, data driven explanation?
Given all these deprecations, constant and costly migrations, I am now considering alternate API prividers, such as Gemini for my future projects. I have been a customer since the API came out, and I really think this latest deprecation isnt healthy for customers.