Model Library
Browse and deploy state-of-the-art AI models through the DEVUP Gateway.
Browse and deploy state-of-the-art AI models through the DEVUP Gateway.
GPT-5.5 Pro is the same underlying model as GPT-5.5 with one thing fixed rather than configurable: execution mode. Every request runs in pro mode, where the model does substantially more internal work before committing to a single final answer. That fixed choice is why it exists as its own model identifier instead of a parameter. It has no fast path — the shallowest effort level accepted is already what other tiers treat as a deliberate escalation — and requests routinely take minutes rather than seconds. It is the model for questions where a wrong answer is more expensive than a slow one.
The same model as GPT-5.5, running permanently in pro execution mode. That is the entire difference, and it explains everything else on this page.
The general tier of this model exposes an execution mode with two settings. standard is the
default; pro makes the model work substantially harder internally before producing a single final
answer.
On this model, pro is not a setting. It is the model. Send a request specifying only an effort
level and the response comes back reporting "mode": "pro" — there is nothing to enable and nothing
to turn off.
That answers a question worth asking: why is this a separate model identifier rather than a parameter on the existing one? Because the behaviour it produces is different enough — in latency, in interface, in accepted settings — that treating it as a flag on a general model would mislead anyone who set it casually.
| Level | Status |
|---|---|
none | Not available |
low | Rejected |
medium | Accepted — the floor |
high | Accepted — the default |
xhigh | Accepted — maximum depth |
There is no fast path on this model. medium here is not a low setting that happens to be the
minimum; it is already substantial deliberation combined with pro-mode execution.
Note that the default is high, not the middle of the range. A request that omits the effort level
gets the second-deepest configuration available.
If you are migrating an effort string from a general-purpose model, check it first. Values that
work elsewhere — none, low — are outside this model's set.
OpenAI's own guidance for this model states that some requests take several minutes to finish, and recommends background execution to avoid timeouts. That is documented behaviour rather than a note about occasional slowness.
A four-minute synchronous request has to survive four minutes of everything between you and the model — client timeouts, proxies, load balancers, a mobile connection, a laptop lid closing. Every layer in that path is somewhere the work can be lost after it has already been done and charged.
Submit it and collect it later. The run continues whether or not anything is still connected.
Design the product for the wait rather than concealing it. A queued job with a notification is a better experience than a four-minute spinner, and it is the only shape that holds up in practice.
The question is not whether this model is better. It is whether your problem is one where a four-minute correct answer beats a ten-second plausible one.
It usually is for architectural decisions you will live with for years, research questions where a wrong premise costs a week, financial and legal analysis where errors surface expensively later, and anything where a faster model already gave you an answer you did not trust.
It usually is not for anything with a person waiting, anything running at volume, or anything where the task is transformation rather than judgment. Those are not marginal calls — a minutes-long response in an interactive path is a broken feature regardless of how good the answer is.
| Model ID | openai/gpt-5.5-pro |
| Context window | 1,050,000 tokens |
| Max output | 128,000 tokens |
| Knowledge cutoff | 1 December 2025 |
| Input | Text, images |
| Output | Text |
| Execution mode | pro — fixed |
| Reasoning effort | medium · high (default) · xhigh |
| Interface | Responses endpoint, including batch submission |
| Cached input discount | Not offered |
Specifications as published by OpenAI. Nothing is disclosed about the model's internals — no parameter count, no architecture, no training detail, no released weights.
| Capability | Value |
|---|---|
input_types | text, image |
output_types | text |
audio_input | Not supported |
video_input | Not supported |
context_window | 1050000 |
max_output_tokens | 128000 |
reasoning | medium, high, xhigh — no none, no low, no max |
reasoning_mode | pro — fixed |
thinking_history | current_turn, all_turns |
streaming | Supported |
tool_calling | Supported |
structured_output | Supported — JSON schema |
background_execution | Supported |
requires_prompt | Yes — text prompt required, image optional |
Alongside effort, the reasoning object carries a context setting:
| Value | Behaviour |
|---|---|
current_turn (default) | Only this turn's reasoning is used |
all_turns | The model may reference reasoning from every turn present in the input |
{ "reasoning": { "effort": "high", "context": "all_turns" } }On a model that reasons this deeply, carrying that work forward matters more than it does elsewhere.
A multi-turn session at current_turn rebuilds its analysis from scratch on every exchange — and
rebuilds it slightly differently each time, which on a long run compounds into inconsistency.
The setting does not create reasoning that is not already in the request. Earlier reasoning has to be present, either through a conversation reference or by replaying the response history yourself. Reasoning also does not transfer between model families — items from another lineage are dropped without an error.
Base URL: https://api.devupai.com/v1 · Model ID: openai/gpt-5.5-pro
This model is served through the responses endpoint. If your application is written against chat completions, this is where the migration is more than a changed model string.
curl https://api.devupai.com/v1/responses \
-H "Authorization: Bearer $DEVUP_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "openai/gpt-5.5-pro",
"input": "We run 40 microservices on Kubernetes against a shared Postgres. Reads are 40x writes and growing. Evaluate read replicas, CQRS with a projection store, and tenant sharding against our real constraint: two backend engineers and no platform team. Say which you would rule out and why, before saying which you would choose.",
"reasoning": { "effort": "high" },
"max_output_tokens": 32768
}'Asking what to eliminate before asking what to pick is worth doing at this tier. The elimination reasoning is frequently more useful than the recommendation, and it is the part a faster model skips.
The pattern OpenAI recommends for this model, and the one that survives a dropped connection.
import os
import time
from openai import OpenAI
client = OpenAI(
api_key=os.environ["DEVUP_API_KEY"],
base_url="https://api.devupai.com/v1",
)
job = client.responses.create(
model="openai/gpt-5.5-pro",
input=analysis_prompt,
reasoning={"effort": "xhigh"},
max_output_tokens=65536,
background=True,
)
print(f"Submitted {job.id} — status {job.status}")
while True:
job = client.responses.retrieve(job.id)
if job.status in {"completed", "failed", "cancelled"}:
break
time.sleep(15)
print(job.output_text if job.status == "completed" else f"Ended as: {job.status}")Persist the identifier somewhere durable before you begin polling. A process that dies holding the only reference to a running job has abandoned work that is still executing and still being charged.
with open("regulatory_filing.txt", encoding="utf-8") as handle:
document = handle.read()
response = client.responses.create(
model="openai/gpt-5.5-pro",
input=[
{
"role": "system",
"content": (
"Work only from the document supplied. Quote the passage supporting every finding. "
"Where the document is silent on something material, say so explicitly rather than "
"reasoning around the gap."
),
},
{
"role": "user",
"content": f"{document}\n\nWhich obligations survive termination, and which of those are unbounded in time?",
},
],
reasoning={"effort": "xhigh"},
max_output_tokens=32768,
)
print(response.output_text)Requiring a quote per finding is cheap to ask for and hard to fake. It turns a confident paragraph into something a lawyer can verify in thirty seconds.
conversation = [
{"role": "user", "content": "Assess this acquisition target's revenue quality from the attached filings."}
]
response = client.responses.create(
model="openai/gpt-5.5-pro",
input=conversation,
reasoning={"effort": "high", "context": "all_turns"},
max_output_tokens=32768,
)
conversation += response.output # carry reasoning items forward, not just the text
conversation.append(
{"role": "user", "content": "Now stress-test your own conclusion. What would have to be true for it to be wrong?"}
)
followup = client.responses.create(
model="openai/gpt-5.5-pro",
input=conversation,
reasoning={"effort": "high", "context": "all_turns"},
max_output_tokens=32768,
)
print(followup.output_text)Appending response.output in full — rather than extracting the text and rebuilding a message — is
what makes all_turns functional. Reasoning items travel in that list; discard them and the setting
has nothing to reference.
The second turn is the pattern worth copying. A model that reasons this deeply is unusually good at arguing against its own conclusion, and unusually unlikely to do it unprompted.
Work that nobody is waiting on suits this tier better than almost any other model.
requests = [
{
"custom_id": f"contract-{index}",
"method": "POST",
"url": "/v1/responses",
"body": {
"model": "openai/gpt-5.5-pro",
"input": f"Identify every clause conflicting with our standard terms. Cite both passages.\n\n{text}",
"reasoning": {"effort": "high"},
"max_output_tokens": 32768,
},
}
for index, text in enumerate(contracts)
]Since the work already takes minutes, submitting a hundred jobs and collecting them later costs nothing in responsiveness you actually had.
import base64
with open("system_architecture.png", "rb") as handle:
encoded = base64.b64encode(handle.read()).decode("utf-8")
response = client.responses.create(
model="openai/gpt-5.5-pro",
input=[
{
"role": "user",
"content": [
{"type": "input_image", "image_url": f"data:image/png;base64,{encoded}"},
{
"type": "input_text",
"text": (
"Trace every path a user request can take through this architecture. For each, "
"name the components that must all be healthy for it to succeed. Describe only "
"what the diagram shows."
),
},
],
}
],
reasoning={"effort": "high"},
max_output_tokens=16384,
)npm install devupaiimport DevupAI from "devupai";
const client = new DevupAI({
apiKey: process.env.DEVUP_API_KEY,
});
const job = await client.responses.create({
model: "openai/gpt-5.5-pro",
input:
"Evaluate this migration plan against our uptime commitment. " +
"List what could go wrong, ordered by how much it would worry you.\n\n" + plan,
reasoning: { effort: "high" },
max_output_tokens: 32768,
background: true,
});
console.log(`Submitted ${job.id} — status ${job.status}`);A model that thinks for minutes rewards prompts written differently from those aimed at fast models.
Supply the constraints, not only the question. Team size, timeline, existing stack, what you have already tried and rejected. A recommendation that ignores your constraints is one you cannot act on, and this is the tier where including them genuinely changes the answer.
Ask for the argument to appear in the output. Not the internal trace — the reasoning. Why this and not that. At this depth the argument is often worth more than the conclusion, and it is what makes the conclusion checkable.
Ask it to argue the other side. "Make the strongest case for the option you rejected." The model does this well and almost never does it unasked.
Send one large question rather than several small ones. Decomposing a problem across requests discards the cross-cutting analysis you came here for, and costs more in total.
Do not iterate here. Develop the prompt on a faster model, then run the final question on this one. Four-minute iteration cycles are not iteration.
| This model | GPT-5.5 | |
|---|---|---|
| Execution mode | pro, fixed | standard by default, pro available |
| Minimum effort | medium | none |
| Default effort | high | medium |
| Chat completions | No | Yes |
| Typical latency | Minutes | Seconds |
| Cached input discount | Not offered | Available |
The last row changes how you structure requests. Without a cached-input discount, a repeated system prompt costs the same on every call — so the common pattern of sending a large fixed preamble with every request has no advantage here. Include the fixed material in the request that needs it, not in every request out of habit.
And if you want pro-mode behaviour occasionally rather than always, the general tier accepts
"reasoning": {"mode": "pro"} on a per-request basis. This model exists for the case where you want
it every time.
medium; there is no way to ask this model for a quick answer.low is rejected, and none is not available.