“ * Developer messages : Specify instructions or context for the model to follow, such as defining tone, style and other behavioral guidance.”
As this is being announced as a new feature, what actually separates it from the System Prompt and does it actually differ technically from System Prompt or is this just the new nomenclature for what still essentially is just the system primer?
First off, sorry about this—we didn’t make this change very clear.
Does this help make things more sense? You can read more about how the model treats the developer and user message role hierarchy in our model spec: Model Spec (2024/05/08).
Thank you @edwinarbus! Much appreciated.
I guess this does not help me understand any differences. For now, they are synonyms, but will they be discrete later? will there be a time where you send both a “system” and a “developer” prompt to an o1 model?
I think we might need to update this reply, I tried “system” the other day and it rejected it, latest communication seems to say stuff is not forward/backwards compatible:
https://platform.openai.com/docs/guides/reasoning
Developer messages are the new system messages: Starting with
o1-2024-12-17, o1 models supportdevelopermessages rather thansystemmessages, to align with the chain of command behavior described in the model spec. Learn more.
Hi @edwinarbus, is it possible to add this to the documentation too as we’ve been quite confused about this.
I tagged this to Documentation since it’s clear docs need to be updated.
developer messages are not converted automatically for 4o, that’s a lie, see this:
openai.BadRequestError: Error code: 400 - {‘error’: {‘message’: “Unsupported value: ‘messages[0].role’ does not support ‘developer’ with this model.”, ‘type’: ‘invalid_request_error’, ‘param’: ‘messages[0].role’, ‘code’: ‘unsupported_value’}}
Also I cannot understand how I am using the OFFICIAL OPENAI’S LIBRARY yet I have to write my own library to interact with the library because it’s so bad, something that should be as simple as changing a string value from “gpt-4o” to “o1-preview” is a pain in the ass. You have to ensure you use SYSTEM instead of DEVELOPER and vice-versa, then you cannot use formatted responses with o1, but you cannot pass ANY value of response_format to the completions.create() function because it rejects it, even rejects None and OpenAI’s NotGiven() class and the NOT_GIVEN object. So you end up having to make two functions, one that is invoked without that argument for o1 and one that is invoked with the argument for 4o. Might as well just run deepseek R1 on my smart fridge.
Actually that error message about “Developer” not being supported, that was using “o1-preview”, I Can confirm that… So yeah, the API is completely broken. Dude, I wanna join OpenAI, I could make a broken python implementation of the API that’s better than that and I also wanna be a millionare.
This is definitely the best answer.
It is very good that you do such conversions behind the scenes, as it’s a great quality of life improvement.
However, the documentation still lacks explanation of what is germane to each family of models. Well, we know what is germane to non-reasoning models, of course.
I tried to think about this conceptually over the past few days.
You have:
non-reasoning models
reasoning models
a chat-focused API
an assistant-focused API
This is rapidly leading to 4 types of parameter arrangements and might become error-prone for the unwary.
Should reasoning models have an API of their own? Should you think of “chat,” “assist,” and “reason” as modes of operation that should fall under a single API?
Unrelated, but also important…
I am very glad to see progress on the conceptualization of prompt hierarchy and the prioritization of prompts at each level. Documenting this is very important, I think.
The temptation would be to allow developers to assign priority factors to levels, but I think it would just make things more unpredictable. Hence, I think you should control and define this, as you are right now.
In fact, the way the hierarchy of prompts works reminds me of the OSI model (OSI model - Wikipedia). I think that approach could be formalized further to establish degrees of model interaction.
Lastly, there is the text of prompts themselves. After using this for a few years now, it has become clear there is often a need for a markup hierarchy inside prompts themselves. This will become even more acute for reasoning model prompts.
An example of what I mean: If you structure your prompt using Markdown at the top level, then Markdown deeper inside the structure of the prompt causes problems.
I have arrived at a markup hierarchy that uses all of: XML, Markdown, Plain Text, JSON.
If the encapsulation of prompt text “makes sense,” I found that most models interpret the input as I do.
That being said, the argument will be that any truly intelligent model will be uncannily good at parsing prompt text regardless of its structure. Until then, though, it will make a huge difference.
Agreed! We’re working on some new docs improvements here that we hope will make things more explicit without hunting around.