platform.openai.com · the settings panel
That left-hand panel is not a preferences screen. Every dropdown on it writes one line of a request that gets sent to a model, and this page walks through what each line does, what it costs, and when you would change it.
Open that page and it looks like a settings screen, the kind where you tick boxes and things quietly improve. It is not one. Nothing on that panel changes your account, your preferences, or the software. Every control writes a value into a single message that gets sent, once, when you press the arrow.
The message is called a request. Each value inside it is a parameter. The thing that receives it is a model: a program that takes text in and produces text out. What comes back is a response.
That is the whole loop, and holding it makes the rest of this page much easier. You are not configuring an application. You are filling in a form, sending it, and getting one answer back. Change a dropdown and nothing happens until you send again, because the dropdown only edits the form.
This is also why the Code button in the top right matters more than it looks. It shows you the exact request the panel has built, in a language you can paste into a program. The panel is a friendly way to write that text. The text is the real thing.
A form at a post office counter. The boxes you tick decide how the parcel travels: next day or surface mail, insured or not, signature required. The clerk does not remember your preferences, and ticking a box changes nothing until you hand the form over. The panel is that form, the send arrow is handing it over, and the model is the postal system that acts on exactly what is written. Every question on this page is really a question about one box on the form.
Before the individual boxes make sense, one of them needs unpacking first, because it is the only one that is not a dropdown and it is where most of your influence actually lives.
Two places on that screen accept typing, and beginners routinely use the wrong one.
The large box on the left, under the heading Prompt, is where you put instructions that should apply to every exchange: who the model is being, what tone to use, what it must never do, what shape the answer should take. This is the system prompt, sometimes called the developer message. The placeholder text on screen is telling you exactly this when it says "describe desired model behavior".
The box at the bottom right, the one saying "Ask anything", is where you put the actual thing you want to know right now. That is a user message.
In the Responses API this box is sent as instructions, a field separate from the conversation itself, which is why it survives when messages do not.
The distinction is a role. Every piece of text in the request is tagged with who it came from: system for standing orders, user for the person, assistant for what the model said back. The model treats them differently on purpose, and it weights the system role more heavily as a standing instruction.
Put "answer in one sentence" in the chat box and it works, once. Three exchanges later the model has drifted back to paragraphs, and this confuses people constantly. It has not forgotten or disobeyed. That instruction is now an old message some distance back in a growing pile, while a system prompt is re-sent, in full, at the top of every single request.
A new assistant on their first morning. The note taped to their monitor saying "always cc me on client email" is read every day, because it is stuck where they cannot miss it. The same words said once in a corridor on Tuesday get followed on Tuesday. The prompt box is the note on the monitor; the chat box is the corridor. Neither is more forceful in the moment, and only one of them is still there on Friday.
So what goes in it? The placeholder offers three hints, tone, tool usage and response style, and a durable prompt has more than that. The parts that earn their place, roughly in this order: role and scope, who the model is acting as and what is outside its remit; the task, stated once and plainly; the output contract, meaning format, length, and what to do when it cannot answer; and constraints, the things it must never do. Put the durable material at the top and anything that changes at the bottom, for a reason that turns out to be financial rather than tidy, and which comes up again later on this page.
One piece of older advice is worth actively unlearning here. Guides written for earlier models tell you to script the procedure: first do this, then do that, then check the other. A reasoning model plans internally, and a rigid script fights that. The current guidance is to give a clear goal, strong constraints and an explicit output contract without prescribing every intermediate step, and for longer work to define what counts as done and how the model should check itself. Describe the destination and the boundaries; leave the route alone.
Underneath the prompt box sits Add messages to prompt, which lets you write out an example exchange: a user message and the ideal assistant reply, saved as part of the prompt itself. This is how you show rather than tell. If describing your desired format takes a paragraph, two worked examples usually beat it, and this is where they live.
Everything you type in either box gets chopped up before the model sees it, into the unit that every other control on the panel is quietly measured in.
The model does not read letters or words. Text is first cut into tokens, chunks of roughly four characters, and those chunks are what gets counted, billed and limited. Scroll through one short request to see where they go.
The system prompt and your question are cut into tokens. In this example that comes to 75 of them. These are the input tokens, and you pay for every one.
Before writing a word of the answer, a reasoning model works through the problem privately. That working is made of tokens too: 1,024 of them here. You never see them.
The visible reply is another 162 tokens. So the total charged as output is 1,186, of which fewer than one in seven is text you actually receive.
Input plus thinking plus answer must fit inside the context window, the model's fixed working space. Hit the ceiling mid-thought and you get a truncated response having paid for everything up to that point.
Almost every control on the panel changes the size of one of these three blocks. That is the single idea the rest of this page rests on.
The proportions in that figure are worth staring at. The thinking block dwarfs both the question and the answer, and it is invisible, and it is billed at the same rate as visible output. A response that looks short can be expensive, and nothing on screen tells you so unless you go looking at the usage numbers.
A taxi meter that runs while the driver sits at the kerb planning the route. You are charged for the planning and the driving at the same rate, the planning happens before the car moves, and the receipt shows one total. A short trip with a long think is not a cheap trip, and the only way to know the split is to read the itemised bill rather than glance at the distance travelled.
The context window deserves one more sentence, because beginners meet it as a confusing error rather than a concept. It is not memory in any lasting sense. It is a desk of fixed size: everything the model can consider must be laid out on it at once, and when the desk is full something falls off the edge.
With tokens in hand, the dropdowns can be taken one at a time, starting with the one that changes the most.
Your screenshot reads gpt-5.4-mini. Three things are packed into that string, and reading it is a skill worth ten minutes.
gpt is the family. 5.4 is the generation, and the numbers climb over time as new ones ship. mini is the size tier: a smaller, cheaper, faster sibling of the full model. You will also meet suffixes naming a specific dated snapshot, which pins you to one exact version so that a model update cannot silently change your results.
Three things move together as you go up the tiers, and only two of them move in your favour. Capability rises. Cost per token rises. Latency, the delay before you get an answer, rises too.
The practical advice runs opposite to instinct. Start at the smallest model that could plausibly work, and move up only when you have seen it fail at your actual task. Starting at the top hides which parts of your problem were ever hard, and you pay for that ignorance on every request afterwards.
Hiring for a job you have not written down yet. The most expensive candidate can certainly do it, and hiring them teaches you nothing about what the job needed. Start with someone cheaper and the first thing they struggle with is the actual requirement, revealed for free. The failures of a small model are a specification for what you really need, which is information you cannot buy by starting at the top.
One caution about the dropdown itself: not every model supports every control below it on the panel. Options grey out or vanish depending on what you pick, and this alarms people who assume they have broken something. They have not. The panel is showing what that model accepts, which is why one setting is worth understanding before any of the others.
That setting is the one that decides whether the model gets to think before it speaks.
Older models began writing the instant the request arrived, one token after another, with no stage in between. A reasoning model inserts a stage: before it writes anything you will see, it produces a stretch of private working, breaking the problem down and considering approaches. That working is made of reasoning tokens.
Three facts about those tokens carry every setting in the next few sections, and each one surprises people.
You do not see them. The raw reasoning is not returned by the interface. You are billed for them, at the output rate. And they take up room in the context window, competing with your prompt and your answer for the same fixed space.
This is the trade the whole reasoning section of the panel exists to manage. Thinking buys accuracy on problems with steps in them: multi-stage arithmetic, debugging, planning, anything where a wrong first move stays wrong. It buys nothing at all on "what is the capital of France", and you still pay for it.
Working out a sum on scrap paper before writing the answer on the form. The scrap paper is thrown away and never handed in, so the marker sees only the final figure. But the paper cost something, the time spent scribbling was real, and on a hard sum it is the only reason the figure is right. Reasoning tokens are the scrap paper: discarded, invisible, charged for, and sometimes the entire reason the answer works.
The documentation makes a point worth passing on, because it saves beginners a lot of wasted money: treat thinking as a tuning knob rather than the first thing you reach for when quality drops. A vague prompt does not get less vague by being thought about harder. Fix the instructions first, then turn this dial.
Which brings us to the dial itself.
This dropdown says how much thinking to do before answering. It is the single most consequential setting on the panel after the model itself, and it is the one to experiment with first.
The old choice was three-way: low, medium, high. It has grown. Depending on the model, the supported values can include none, minimal, low, medium, high, xhigh and max. Which ones exist is model-dependent rather than universal, so the dropdown will show you a different list for different models, and that is expected rather than broken.
Defaults are model-dependent too. GPT-5.5, for instance, defaults to medium, described as the best starting point for its balance of quality, reliability and performance.
One detail that reads as a footnote and is not: the models reason adaptively. Setting a high effort does not force long thinking on an easy question. It raises the ceiling rather than the floor, so the model spends fewer tokens on simple tasks and more on complex ones within whatever setting you choose.
The official guidance for each rung is worth having in one place, because the names alone do not tell you when to use them.
none is for latency-critical work that gains nothing from reasoning: voice, fast retrieval, classification. For latency-sensitive cases the advice is to try low first and drop to none only if you need to. low gives efficient reasoning for a modest delay, suited to tool use, planning and multi-step decisions where speed and cost matter: data analysis, drafting, support workflows.
medium is the default for most work, the balanced point where quality and reliability matter and the task involves planning and judgement. high is for hard reasoning, complex debugging and deep planning, and the documentation suggests evaluating both medium and high rather than assuming higher is better.
xhigh is for deep research and long agentic runs, and comes with an explicit warning: use it only when your tests show a clear benefit that justifies the extra latency and cost. max sits above that for the most complex tasks, worth evaluating if you are already on xhigh.
Telling a colleague how long they have before you need an answer. Five minutes and you get a first instinct. A day and you get something checked. A week and they will go and read the literature. You are not making them smarter, you are buying a different amount of their attention, and asking for a week on a question with an obvious answer wastes six days for no better result. It also means the answer arrives a week later, which is sometimes the thing that matters most.
There is a second reasoning control on the panel, sitting directly above this one, and the two are routinely mistaken for versions of each other.
Your screenshot shows Reasoning mode set to standard. GPT-5.6 models support standard and pro, with standard as the default, and pro intended for difficult tasks that need more model work and can tolerate higher latency and token usage.
Here is the part that gets misread. Mode and effort are independent. Mode selects standard or pro execution; effort controls how much reasoning happens within whichever mode you picked. They are not two names for one slider, and setting one does not set the other. If you leave effort alone, GPT-5.6 defaults to medium in both modes.
So there are four corners, not a single line: standard at low effort, standard at high effort, pro at low effort, pro at high effort. They are different things to buy.
What pro mode actually does is aggregate the model work performed to produce the final answer, billing those tokens at the selected model's standard rates. It performs more model work than standard mode, which increases token usage and cost. There is no separate pro price list here; you pay the model's usual rate for a larger amount of work.
The difference between giving a researcher more time and giving them a team. More time is effort: the same person, thinking longer. A team is mode: several passes at the problem, pooled into one answer. You can give a team five minutes or give one person a week, and those are different purchases that happen to both cost more than one person for five minutes.
For a beginner the honest advice is: leave this on standard. Reach for pro when you have a genuinely hard task, you have already tried high effort on standard, and you can wait. It is not the setting that fixes a disappointing answer, and it is an easy way to spend a lot of tokens on a question that never needed them.
Everything so far has been about the invisible half of the response. The next control governs the half you actually read.
This one is refreshingly simple, and it is constantly confused with the previous two. Verbosity takes low, medium or high, and it steers how long the visible answer is. Low gives you terse replies. High gives you thorough ones with more explanation and context.
It does not change how hard the model thinks. Effort governs the private working; verbosity governs the public text. You can pair them however you like, and two of the four combinations are genuinely useful in ways beginners rarely discover on their own.
High effort with low verbosity is the combination worth knowing about: think hard, then just tell me the answer. That is what you want for a difficult classification, a yes-or-no judgement on a tricky case, or a single number that took real work to compute.
Low effort with high verbosity is its mirror: don't labour over it, but write it out fully. Useful for drafting and explanation where the task is easy but the output should be complete.
Asking a structural engineer whether a wall can come down. How long she spends checking is one question. Whether she replies "yes" or sends four pages on load paths is a completely different one. A one-word answer can sit on top of a week of checking, and a very long reply can be produced without much thought at all. Length is not evidence of care, in engineers or in models.
A related control lives elsewhere, in the API rather than this dropdown: a hard cap on output tokens. Verbosity is a request about style, and the model interprets it. A cap is a wall, and hitting it truncates the reply mid-sentence. Use verbosity to ask for brevity; use a cap to protect yourself from a runaway bill, not to shape prose.
One control down from verbosity is the setting that decides whether you get any glimpse of the thinking at all.
The raw reasoning tokens are not exposed. What the Summary setting gives you is a written summary of the model's reasoning, produced separately and returned alongside the answer.
The values you will meet are auto, concise and detailed, and support varies by model: the computer-use model supports concise while o4-mini supports detailed, and setting auto gets you the most detailed summariser that particular model offers. For most reasoning models today auto amounts to detailed. Your screenshot shows auto, which is the sensible default.
Two practical notes. Summaries are opt-in, so nothing appears unless you ask. And with the newest reasoning models you may need to complete organisation verification before summarisers are available, which catches people out as a mysterious missing feature rather than a permissions step.
What is it for? Debugging, mostly, and trust. When an answer is wrong in a puzzling way, the summary often shows you the model misread the question three steps back, which points at a prompt fix rather than a settings fix. It is also what powers those "thinking about..." lines you see in chat interfaces.
A minute-taker's account of a meeting you did not attend. It tells you what was decided and roughly why, written afterwards by someone summarising. It is not a recording, and a detail absent from the minutes might still have been said. The summary is a description of the reasoning rather than the reasoning itself, which makes it useful for understanding and unreliable as proof of exactly what happened.
Worth knowing: at the lowest effort settings there may be little or no reasoning to summarise, so asking for a summary can return nothing. That is consistent behaviour rather than a fault.
So far every control has shaped what the model says. One control decides the shape it must say it in.
Set to text, the model replies in ordinary language. That is what you want when a person is reading the answer, and it is the right default for the Playground.
The alternatives matter the moment a program is reading the answer instead. JSON is a plain-text format for structured data, all labelled fields and values, which code can read reliably and humans find fussy. A schema is a description of exactly which fields must be present and what type each one is.
Choose a JSON schema format and you get structured outputs: the model is constrained to produce output matching the shape you defined. Not asked politely. Constrained.
The mechanism is worth knowing because it explains the guarantee. Rather than being asked and then checked, the model is constrained during generation: a grammar engine masks tokens that would break the schema before they can be produced, so a non-conforming response is not rejected afterwards, it is unable to occur. In the Responses API the schema goes under text.format, with type, name, schema and strict as siblings.
There is an older middle option, json_object, usually called JSON mode. It guarantees valid JSON syntax and nothing about your fields, and it is now regarded as legacy. Valid JSON of the wrong shape still breaks your program, so this setting solves the smaller half of the problem.
The difference between asking and constraining is the whole value. Write "reply as JSON with name and age" in your prompt and it usually works, then one day the model wraps it in a code fence, or adds a friendly sentence first, or names the field full_name. Your program crashes on the exception rather than the rule, at whatever hour it happens.
The difference between asking people to write their date of birth "in the usual format" and handing them a form with three labelled boxes: day, month, year. Nearly everyone gets the request right. The form makes the wrong answer impossible to write down. A schema is the boxes, and the reason to prefer it has nothing to do with how well the request usually works and everything to do with the day it does not.
When to use which: text for anything a person reads, and for exploring in the Playground. A schema whenever the output feeds code, populates a database, or gets compared against other outputs. If you are extracting fields from documents, classifying into fixed categories, or building anything that runs unattended, this is the setting that turns an occasional mystery crash into a non-event.
Two limits that catch people, and both are about mistaking a structural guarantee for a factual one. A schema can require a priority field restricted to low, medium or high; it cannot make the model pick the right one. And if you hand it text that has nothing to do with your schema, it will often fill the required fields anyway, so OpenAI's own advice is to give explicit instructions for input that cannot produce a valid answer. Include a field for "not found" rather than forcing a confident value into every box.
Structured outputs also add a failure mode that did not exist before: the model may return a refusal instead of your object. Code that goes straight to parsing will break on it, so check for the refusal first. A useful summary of the whole feature is typed output from an uncertain reader.
The panel's remaining sections are about not retyping all of this tomorrow.
Write a prompt that summarises one particular contract and you have solved today. Write it with a variable where the contract goes and you have built a tool.
A variable is a named placeholder inside your prompt text. Add one in the Variables section, and the same prompt can be run against a hundred different inputs by swapping the value rather than editing the instructions. This matters more than it sounds: when the instructions are edited each time, you can never tell whether a better result came from the new input or from the wording you changed along the way.
The two buttons above the prompt box serve the same end. Templates gives you prepared starting points. Generate prompt goes the other way: describe what you want in plain language and it drafts a structured prompt for you, which you then edit. For a beginner staring at an empty box, that draft is a genuinely useful thing to react to, and reacting to a draft is easier than starting from nothing.
A rubber stamp against handwriting the same letter every time. The stamp leaves a blank for the name, so a hundred letters go out identical except where they are meant to differ. Handwrite them and every copy differs slightly, and when one recipient reacts badly you cannot tell whether it was the letter or that day's handwriting. Variables are the blank on the stamp.
Saving is not just tidiness. A saved prompt becomes an object with an id like pmpt_123 and a version number, and your code can call it by that id, passing values for the variables at run time rather than carrying the prompt text around. That is what makes the Playground a place to author something rather than a scratchpad: edit and save a new version, and every caller pointing at that id picks it up without a code change. Worth knowing the current limit too, which is that these saved prompts are created and edited in the interface rather than through the API.
Generate prompt has one trap worth naming. The prompt it writes is fluent and looks authoritative, and beginners tend to accept it whole. Read it as a first draft from someone who has never met your problem: the structure is usually good, the specifics are guesses. The parts that matter, your actual constraints and edge cases, are the parts it could not have known.
All of this so far assumes the model works alone with the text you gave it. The last section of the panel removes that assumption.
A model on its own can only work from the text in front of it. A tool is a capability you switch on that the model can choose to use partway through answering. Scroll through one request that uses one.
The request now carries a list of what the model is allowed to use. Switching one on is permission, not an instruction: the model decides whether it needs it.
Partway through, it decides it cannot answer from what it has. Instead of guessing, it emits a tool call: a structured request naming the tool and what it wants.
Because these are hosted tools, this happens on OpenAI's side. A web search is performed, a file is searched, code is executed. You write no plumbing.
Whatever the tool returned is appended and the model resumes with it in context. Note what just happened to your token count: those results are input tokens you are now paying for.
One answer may involve several loops. This is why tool-using requests are slower and dearer than they look, and why reasoning effort interacts with them so strongly.
The ones you are most likely to meet: web search, for anything current or beyond what the model was trained on. File search, which retrieves from vector stores of documents you have uploaded. Code interpreter, which runs Python in a sandbox that already has numpy, pandas and matplotlib, and is the honest way to do arithmetic and data analysis rather than trusting a model to compute in its head. Image generation, which can stream previews and take multi-turn edits. And MCP and connectors, an open protocol for reaching services outside OpenAI entirely.
Further down the list sit the ones aimed at agents rather than chat: computer use, shell, apply patch, and tool search, which defers a large set of tool definitions until runtime so the model loads only what this turn needs. That last one exists because tool definitions are themselves tokens, and a remote server exposing dozens of endpoints can add hundreds of tokens of names and schemas to every request before you have asked anything.
These are billed separately from tokens, and the amounts are worth knowing before you switch four of them on: code interpreter is priced per container, file search charges for vector storage per day plus a rate per thousand calls, and the remote MCP tool adds no fee of its own, so you simply pay for the tokens it produces.
The difference between a consultant answering from memory in the room and one who says "give me a minute, I'll look it up". The second is slower, bills for the time spent looking, and is right about things that changed last week. Switching on a tool is telling them they are allowed to leave the room; they still decide whether the question needs it.
Two cautions. Tools make results non-reproducible: the same request twice can retrieve different pages and give different answers, which is a feature for currency and a problem for testing. And every tool result is text entering your context window, so a chatty tool can crowd out the room reasoning needs.
That accounts for every control the panel offers. The next thing worth understanding is a control it pointedly does not.
Anyone who has used the older Playground will notice something gone. There is no temperature slider on that panel. No top_p, no frequency penalty, no presence penalty. For years those were the first things a beginner was told to adjust, and now they are not there at all.
They were not moved or hidden. The model you have selected does not accept them.
Here is what they did. At each step a model produces a probability for every possible next token, and sampling is the act of choosing one. Temperature reshapes those probabilities before the choice: low values concentrate weight on the likeliest token, making output repeatable and flat, while high values flatten the distribution and let unlikely tokens through, which reads as creativity or as nonsense depending on how far you pushed it. Top_p did a related job by a different route, keeping only the most probable tokens whose weights sum to a threshold and discarding the rest.
Reasoning models disable them. Send one anyway and you do not get a slightly different answer, you get a 400 error saying the parameter is not supported. Temperature, top_p and n are fixed at 1; the frequency and presence penalties are fixed at 0.
The rule has an exception, and it is the reason the panel looks inconsistent from one session to the next. On GPT-5.1 and later, temperature, top_p and logprobs come back when reasoning effort is set to none. With the thinking stage switched off there is no calibrated process to disturb, so the sampling dials mean something again and the panel offers them. Turn effort up and they disappear. Availability is not decided by the model name alone; it depends on whether that model is currently reasoning, which is why two people on the same model can honestly disagree about whether the setting exists.
Older GPT-5 models and the Pro variants reject temperature at any effort level. If you meet these dials, on a non-reasoning model or at effort none, tune one and leave the other at 1 rather than moving both, and do not expect temperature 0 to give you identical output twice: determinism depends on how the model is served, not on anything you can set from here.
Why remove a knob people liked? Because these models do not generate in one clean pass. Their internal process involves rounds of reasoning, verification and selection, and that process is calibrated. Letting a caller flatten the probabilities underneath it would disturb machinery that was tuned as a whole. OpenAI chose to reject the parameter rather than accept it and quietly ignore it, so you always find out when a setting would have had no effect.
The tuning pegs on a piano. On a simple instrument, loosening one string is a legitimate way to change the sound. Inside a machine that tunes itself between every note, a peg you can turn from outside is not a feature, it is a way to break the tuning. The peg was removed because the instrument now does that job internally, and the two steering controls you were given instead, effort and verbosity, act on the process rather than on the strings.
The practical consequence: if you are following a tutorial written before all this, and it tells you to set temperature to 0.2 for reliable extraction, that advice no longer applies to these models. Reach for a schema instead. If it tells you to raise temperature for more varied output, ask for variety in the prompt, or run the request more than once.
One more thing the panel does not show you, and it is the one that pays for itself fastest.
The panel is a friendly subset. A handful of things that matter appear only in the request itself, which is why the Code button is worth pressing early rather than at the end.
Max output tokens is a hard ceiling on everything the model generates, reasoning included. It is not a style request the way verbosity is; it is a wall, and hitting it returns a response marked incomplete. The dangerous version, worth repeating because it costs real money quietly, is running out during the thinking stage and receiving nothing at all while still paying for the input and the reasoning.
Prompt caching is the one nobody tells beginners about, and it is the reason the last section said to put durable material at the top of your prompt. Requests repeat a great deal: the same system instructions, the same tool definitions, the same opening messages. When a request arrives carrying a prefix the system has recently processed, it can be routed to a server that already computed that prefix and reuse the work instead of doing it again. It applies automatically, costs nothing extra to use, and can cut time to first token by up to 80 percent and input token costs by up to 90 percent.
The mechanism is what makes the ordering rule non-negotiable rather than a matter of taste. Caching works on a prefix: the opening stretch of the request, which must run to at least 1,024 tokens to be eligible at all. A change before that point changes the prefix and you lose the hit. A change after it does not invalidate anything. So stable content first, byte-identical, every time; the part that varies last. Reword your system prompt between runs and you have thrown the discount away on every request that follows.
This is also the second, harder argument for Variables. Pulling the changing value out of the instructions is not only good experimental hygiene, it keeps the prefix identical, which is what the cache is matching on. Edit the wording by hand each run and you pay full price each run.
A kitchen prepping the same base sauce every morning. Make it once and ladle from it all day and the cost is paid once. Start each dish from raw onions because you reordered the recipe card, and you pay full price for the identical work every time. Caching rewards you for not fiddling, which is the opposite of the instinct that makes people tweak a system prompt between every run.
There is also streaming, which sends the answer token by token as it is produced rather than in one block at the end. It changes nothing about cost or quality and everything about how waiting feels, which is why almost every chat interface uses it. The Playground streams by default; your own code has to ask.
All of which leaves the four things around the edges of the screen.
These four sit around the edges and none of them change what the model says.
Store logs, the toggle at the bottom of the Model section, controls whether the request and its response are retained so you can look at them later in your dashboard. On is convenient: you get a history to debug against and to build evaluations from. Off is what you want when the content is sensitive, and turning it off has a technical consequence worth knowing, because stateless requests handle reasoning continuity differently across turns.
Compare, top right, runs the same prompt against two configurations side by side. This is the most underused control on the page. Every question this explainer raises, whether high effort is worth it, whether the mini model is enough, is answerable in about a minute here, on your actual task, rather than by argument.
Code shows the request as code you can paste into a program. When you are done experimenting, this is the door out of the Playground and into something real.
Draft and "Unsaved changes" are ordinary document status. Your work is not saved yet. Save it and it becomes a named, versioned prompt you can reuse.
The parts of a kitchen that are not cooking. The notebook where you write what you tried, the two pans on the hob so you can taste the difference, the written-up recipe you hand to someone else, and the label saying this one is not finished. None of them change the food, and without them you cannot repeat a success or explain it to anyone.
The useful order to work in, if you want one: write the prompt properly first, pick the smallest plausible model, leave effort at its default, and change exactly one thing at a time with Compare open. Most of the disappointment beginners have with these settings comes from turning three dials at once and then reasoning about which one helped.
Every dropdown on that panel buys tokens, time, or certainty. Knowing which one you are short of is most of the skill.
press s for the deeper cuts
There are two ways to talk to these models. Chat Completions is the older shape and is still supported; the Responses API is the newer one, and OpenAI states you get improved model intelligence and performance by using Responses with reasoning models. Part of the reason is that Responses can carry reasoning state between turns rather than throwing it away, so the model resumes rather than restarting. The Code button will show you which one the panel is building.
Nothing replaced it one-for-one, which is why the transition confuses people. Sampling parameters acted on token selection; the controls you get now act on the process. Reasoning effort changes how much work happens before generation, and verbosity changes how long the result is. If what you actually wanted from a low temperature was reliable structure, the honest replacement is a JSON schema, which guarantees the thing temperature only ever made more likely. If what you wanted was variety, ask for it in the prompt or sample the request more than once.
Non-reasoning models still accept temperature, top_p, and the frequency and presence penalties, so the older advice is not wrong everywhere, just wrong for the models on this panel. This is also why libraries and wrappers break in a characteristic way: code that always attaches a temperature works fine until someone selects a reasoning model, then returns a 400 that looks like an authentication or version problem rather than a parameter one. If you build a model picker, strip sampling parameters when a reasoning model is chosen.
The response usage object reports a cached_tokens figure, which is the only honest way to know whether your prefix is being reused rather than assumed. Send the same long prompt twice in quick succession and compare: the first is a write, the second should read. Cached prefixes fall out of use after a short idle period, in the region of five to ten minutes on automatic caching, so a workload that trickles will hit less often than one that runs steadily. Caching is scoped to your organisation, so nothing leaks between accounts, and it is compatible with zero data retention because the cache stores computation rather than your content.
Three settings look similar and are not. Plain text is free-form. JSON mode, the older json_object option, guarantees the output parses as JSON and says nothing about which fields appear. A strict JSON schema guarantees the shape itself. The middle option is now treated as legacy for good reason: valid JSON with the wrong field names breaks your code exactly as thoroughly as invalid JSON, and it does so intermittently, which is worse. Note also that strict mode rejects some JSON Schema features outright rather than ignoring them, so a schema that works elsewhere may need trimming.
There is a `reasoning.context` parameter with values `current_turn` and `all_turns`. The GPT-5.6 family supports `all_turns` and uses it by default, rendering compatible reasoning items from earlier turns into the next sample; earlier models default to `current_turn`. This is continuity rather than exposure, since the reasoning items stay opaque and their text is never returned. It only has an effect when the request can reach earlier response items, which is why it interacts with whether you store responses.
In stateless mode, which applies when store is false or your organisation uses Zero Data Retention, reasoning items come back with an `encrypted_content` property by default. You can pass that to later calls to preserve continuity without OpenAI retaining anything. It is a neat resolution of a real tension: you keep the benefit of continued reasoning without the storage, at the cost of having to replay the history yourself.
If generated tokens hit the context limit or your max output cap, you get a response with status `incomplete` and a reason of `max_output_tokens`. The nasty version is that this can happen before any visible output at all, so you pay for input and reasoning and receive nothing. OpenAI recommends reserving at least 25,000 tokens for reasoning and output while you are learning what your prompts need.
The response carries a usage object, and inside `output_tokens_details` there is a `reasoning_tokens` count. That is the only honest way to know what your effort setting is costing you. The worked example in the documentation shows 75 input tokens against 1,186 output tokens, of which 1,024 were reasoning. Check this on your own prompts before deciding an effort level is affordable.
For long-running or tool-heavy flows with some GPT-5 models, assistant messages carry a `phase` field: `commentary` for intermediate updates like preambles before tool calls, and `final_answer` for the completed answer. It is optional but recommended, because a missing or dropped phase can cause a preamble to be treated as a final answer, which looks like the model stopping early for no reason.
The old advice to spell out every intermediate step works against these models. The guidance is to give a clear goal, strong constraints and an explicit output contract, without prescribing every step, and to define what counts as done for agentic work. Treating effort as a tuning knob rather than the main quality lever belongs to the same idea: describe the destination well and let it choose the route.