GPT-5.6-Cyber: what it is and who can actually get it

What GPT-5.6-Cyber actually is

I build integrations and APIs at eesel, so the first thing I do with any model launch is go looking for the model ID and the rate. With this one, neither exists in public. That absence is the whole story.

GPT-5.6-Cyber is OpenAI's cybersecurity-specific model, announced on 10 August 2026. It is built on top of Sol, the flagship of the GPT-5.6 family, and trained to do two distinct things: improve on specialised tasks like finding zero-day vulnerabilities and developing exploit chains, and reduce refusals on higher-risk dual-use cyber work.

Those two goals are worth separating, because they usually get mashed together into "the unlocked model." Reduced refusals is a policy change. Improved zero-day discovery is a training change. GPT-5.6-Cyber does both, and as you will see further down, the two do not always move in the same direction.

Sol, Terra, and Luna are capability tiers you select in the API, the same way you pick a reasoning effort or reach for Sol Ultra on a hard task. Cyber is not. There is no gpt-5.6-cyber model ID you can drop into a request to the OpenAI API. You apply, you get vetted, and only then does the model exist for you.

If you came here from the GPT-5.6 review wondering whether this is a fifth tier, it is not. It is a parallel track with its own door.

Daybreak Blue and Daybreak Red are not two sizes of the same thing

This is the part most write-ups got wrong, and it changes what you should actually apply for.

Daybreak now runs two access tiers. Daybreak Blue gives you frontier general-purpose models, Sol included, with the system-level cyber guardrails removed. Daybreak Red gives you the purpose-trained cybersecurity models, which today means GPT-5.6-Cyber.

The instinct is to read Blue as the cheap tier and Red as the real one. That is not the shape of it. Blue is not a smaller quota of Red. Blue is the same frontier model with a screening layer lifted off it. Red is a genuinely different model with different training.

That distinction matters because OpenAI is unusually direct about which one you should want. In its own words, Blue "is the recommended starting point for most defenders," covering vulnerability discovery, secure code review, malware analysis, incident response, and patch validation. Red is reserved for teams whose authorised work includes advanced vulnerability research, exploit development, or red teaming.

In production, OpenAI screens cyber-related requests to prevent misuse, and it concedes those screens "can also block legitimate defensive work." Blue exists to remove that friction. Red exists because even with the screens off, Sol still declines some highly dual-use prompts, like pentesting a production system.

<div class="dbtier-card dbt-b">
  <span class="dbtier-tag dbtier-tag-red">Daybreak Red</span>
  <p class="dbtier-lead">Red is the right ask, but start on Blue anyway.</p>
  <p>GPT-5.6-Cyber is trained for exactly this: exploit-chain development, authentication bypass, privilege escalation, novel zero-day discovery.</p>
  <ul>
    <li><strong>Completion rate on advanced prompts:</strong> 95.0%, against 57.3% for GPT-5.5-Cyber</li>
    <li><strong>The catch:</strong> shorter, less detailed vulnerability reports than plain Sol, and noticeably higher token usage</li>
    <li><strong>Required:</strong> hardware security key on your account from 1 September 2026</li>
  </ul>
</div>

<div class="dbtier-card dbt-c">
  <span class="dbtier-tag dbtier-tag-part">Partner Program</span>
  <p class="dbtier-lead">Different door entirely, and read the fine print.</p>
  <p>The Daybreak Cyber Partner Program lets approved vendors put these models inside their own products, managed services, and customer engagements.</p>
  <ul>
    <li><strong>Who is in:</strong> Accenture, IBM, CrowdStrike, Cisco, Palo Alto Networks, Cloudflare, Sophos and others</li>
    <li><strong>The catch:</strong> model access stays with the partner and is not passed to the customer. You buy the outcome, not the model</li>
    <li><strong>No guarantee:</strong> OpenAI states that submitting interest does not guarantee inclusion or access</li>
  </ul>
</div>

<div class="dbtier-card dbt-d">
  <span class="dbtier-tag dbtier-tag-none">No application</span>
  <p class="dbtier-lead">There is nothing here for you yet, and that is deliberate.</p>
  <p>Both tiers gate on identity verification, approved-use restrictions, and legal attestations tied to authorised work. Curiosity is not an authorised use.</p>
  <ul>
    <li><strong>What you can still use:</strong> standard Sol, which answers 1.5% of the advanced set and is state of the art on published cyber benchmarks anyway</li>
    <li><strong>Worth knowing:</strong> Sol scores 96.7% on capture-the-flag challenges and 73.5% on ExploitBench without any Daybreak access</li>
  </ul>
</div>

The 95% number is about refusals, not accuracy

To measure the change, OpenAI built an internal evaluation it calls the Advanced Cybersecurity Completion Rate. It tracks how often a model will respond to requests involving exploit-chain development, authentication bypass, privilege escalation, and similar advanced scenarios.

Two things in that chart deserve more attention than the 95%.

The first is the gap that barely exists. Sol with safeguards enabled sits at 1.5%. Sol through Daybreak Blue sits at 2.0%. Lifting the system-level guardrails moves this particular number by half a percentage point. That is not a failure of Blue, it is a statement about what the eval contains: these are the prompts where the model itself declines, not where a screening layer intercepts. If you were hoping Blue would unlock exploit-chain work, it will not, and OpenAI is upfront about that.

The second is GPT-5.5-Cyber at 57.3%. The previous cyber model already existed and already refused researchers roughly two times in five. OpenAI explicitly frames the jump as "addressing feedback from security researchers who encountered persistent refusals with the earlier model." So the pitch here is less "new capability" and more "we finally stopped arguing with you."

What the number is not is a measure of correctness. A model that confidently answers a bad exploit question 95% of the time scores 95%. Keep that separate in your head from the benchmark scores, which do measure whether the work is any good.

It is the same care you need reading any vendor's own eval. We made the same point comparing GPT-5.6 against Claude: the number matters less than what the number counts. If you want a structured way to check that on your own workloads, OpenAI's agent evals tooling is the honest starting point.

Where GPT-5.6-Cyber is worse than plain Sol

Here is the section I would want if I were deciding whether to spend three weeks on an application.

OpenAI ran GPT-5.6-Cyber against an internal Vulnerability Discovery and Report Writing evaluation, which scores an agent on finding severe and actionable vulnerabilities, building a working proof of concept, and submitting a high-quality report. Both new models beat GPT-5.5-Cyber. But GPT-5.6-Cyber performs worse than GPT-5.6 Sol on it, and OpenAI's stated reason is that the specialised model "sometimes produc[es] shorter, less detailed vulnerability reports."

The same pattern shows on ExploitBench, which builds a V8 vulnerability into a full exploit with defensive protections left on. In the standard setting, capped at 300 turns, Sol through Daybreak Blue "solves tasks more token-efficiently and performs best." Push out to 600 turns and the gap narrows, but the standard setting is the one most teams will actually run.

There is a cost dimension underneath this too. OpenAI notes in a footnote that GPT-5.6-Cyber "tends to be more extensive and comprehensive than GPT-5.6 Sol in its reasoning budget, leading to higher token usage." Even if the two models were priced identically, the same task would cost you more on Cyber.

So the honest framing is a trade. You are buying engagement on prompts Sol declines, and novel zero-day discovery, and you are paying for it in report quality, turn efficiency, and tokens. For a red team that keeps hitting refusals, that trade is obviously worth it. For a blue team that mostly needs good writeups, it is a downgrade dressed as an upgrade.

Anyone who has read our Sol review will find this familiar. The flagship is very hard to beat on general reasoning, and specialised variants tend to win narrowly rather than broadly. That was true of GPT-5.3 Codex against the general models too.

What it actually found

Benchmarks are arguable. Bugs in shipped software are not.

OpenAI used GPT-5.6-Cyber to investigate V8, the JavaScript engine behind Chrome, and turned up two previously unknown vulnerabilities that could be chained together to corrupt memory and escape the V8 heap sandbox. Researchers validated the findings and reported them to Google through coordinated disclosure. Google fixed one and assigned it CVE-2026-15903.

The mechanism is specific enough to be worth stating. V8's optimizing compiler skipped a safety check when converting values to integers, so an undefined value could produce an unexpectedly large number. Used as an array index, that number lets the compiler assume it falls inside the array's bounds and omit the usual check, which opens up reading or overwriting memory belonging to other objects. Escaping the heap sandbox from there needs a second vulnerability, and the model found that one too.

Beyond V8, OpenAI reports at least five vulnerabilities in an unnamed popular mobile operating system including a chain from an untrusted app to local privilege escalation, three critical vulnerabilities in a popular database with a remote path to code execution, and over 400 privilege-escalation vulnerabilities in a popular OS kernel.

That last figure is the one to sit with. Four hundred findings is not a research result, it is a triage backlog, and it is exactly the bottleneck OpenAI says Daybreak exists to unblock. Anthropic is pushing the same direction from the other side, which we covered in Claude Code security and again when comparing the OpenAI and Anthropic APIs.

One trusted early customer went on the record:

"[GPT-5.6 Cyber] is materially improving our specialist vulnerability-research workflows: it reasons more accurately about real exploit constraints, tracks complex state better, and has completed work in under a day that earlier models had not resolved after weeks of intermittent effort."

Jared Atkinson, CTO, SpecterOps

Worth reading that carefully. The claim is about specialist vulnerability-research workflows, and it comes from a firm that does offensive security for a living. It is not a claim that Cyber is the better model for general defensive work, which is consistent with everything above.

Why this shipped when Astra did not

Three days before this launch, OpenAI delayed Astra, a forthcoming model, after it reached critical hacking abilities in safety testing. Then it shipped a model explicitly designed to be more permissive on cyber. That looks contradictory until you look at the thresholds.

OpenAI's Preparedness Framework defines exactly two rungs for a tracked capability: High and Critical. They are not points on a sliding scale, they are commitment triggers. High means the model can ship, but only with safeguards that "sufficiently minimize the associated risk of severe harm before they are deployed." Critical means development itself pauses until Critical-standard safeguards exist.

Worth knowing that there is no Low or Medium rung to fall back to. A model is either below the bar, at High, or halted. Rival labs draw the line differently, which is part of why our GPT-5.6 vs Gemini 3 comparison ends up being as much about deployment policy as about scores.

For cybersecurity, the Critical bar is a model that can "identify and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems without human intervention," or devise and execute end-to-end attack strategies against hardened targets from a high-level goal alone.

GPT-5.6-Cyber reached High and not Critical, the same classification as Sol. OpenAI's phrasing is that the model "improved over GPT-5.6 Sol on some specialized cyber tasks that we directly trained for, but not sufficiently to reach our Critical threshold." Astra crossed the line. Cyber did not. That is the whole difference.

OpenAI also states plainly that GPT-5.6-Cyber was not involved in the Hugging Face incident, which is worth noting given the timing.

What defenders were already saying

The model is a day old, so there is no real verdict on it yet. But the grievance it answers has been loud for months, and reading it explains the launch better than the benchmark table does.

The complaint is not that the models are incapable. It is that they find the bug and then decline to discuss it:

"Thing is, you WILL encounter refusals with Sol doing anything remotely adjacent to security work. Which for Codex Security is kinda... problematic. Just a few days back, I was reviewing some small bit of legacy DSA signature verification code, to get a sense of how safe it is to reuse - purely defensive, precautionary work and the context of it was there. But I simply wasn't able to use Codex Security: it threw refusal tantrums on every step of the way."

vsl, Hacker News

That is a defensive code review on legacy signature verification, blocked. In the same thread, an OpenAI-side account conceded the point and pointed at Trusted Access as the remedy, which is precisely the mechanism this launch scales up.

The pushback is just as consistent, and it is not a fringe view. On the thread about US government vetting for GPT-5.6, the top-voted reading was blunt:

"This is regulatory capture in action. This will make it hard/impossible for new vendors to come into the market and only established companies will get to play, and charge, for LLMs. What does this mean for open source? Will it become illegal to download weights?"

jmward01, Hacker News

Both things are true at once. Defenders genuinely were being blocked on legitimate work, and the fix genuinely does concentrate the strongest cyber capability in the hands of whoever passes a vetting process. Anyone weighing open-weight alternatives is doing it partly for this reason.

Getting access, step by step

There are three doors, and they lead to different places.

Individuals verify their identity and request trusted access through ChatGPT's cyber page. Organisations apply for their teams through OpenAI's enterprise access form. Security vendors and consultancies join the Daybreak Cyber Partner Program, which currently includes Accenture, IBM, CrowdStrike, Palo Alto Networks, Cisco, Cloudflare, Sophos, Fortinet, Akamai, and a set of consultancies.

Whichever door you pick, OpenAI controls access with identity verification, account security, monitoring, approved-use restrictions, and legal attestations. Two operational details will bite teams that skim past them:

1. Hardware security keys become mandatory for all individual Daybreak accounts from 1 September 2026. If you are on TOTP today, that is a procurement task with a deadline. OpenAI has arranged preferred pricing with Yubico for accounts that need keys.
2. The partner route does not hand you the model. OpenAI is explicit that "access to the underlying models remains with the approved partner and is not transferred directly to the customer." Going through CrowdStrike gets you the work product, not an API key.

On top of that, OpenAI is nudging Daybreak customers using Codex away from full-access mode and toward auto-review mode, which evaluates actions needing elevated permissions before they execute. Its own recommended practices are worth repeating because they are the sort of thing teams skip: sandbox and isolate the workflow away from production and the open internet, monitor every agent action, and define authorised scope explicitly with permission profiles.

If your org already runs ChatGPT Enterprise, none of that carries over automatically. Daybreak is a separate approval on top, not a seat entitlement. The same is true if you reach OpenAI models through Azure rather than directly.

What OpenAI has not published yet

Two gaps are worth tracking, and both are the kind of thing that quietly matters more than the launch-day benchmarks.

There is no system card. OpenAI says it "will publish a system card with further evaluations of GPT-5.6-Cyber at a later date." Until that lands, the only evaluation numbers available are the ones OpenAI chose to put in the announcement.

There is no price. This one is more interesting than it looks. OpenAI's public API price card has a "Specialized models" section, and that section carries a Cyber row. The model listed is gpt-5.4-cyber, two generations old, and its input, cached input, and output columns are all literal dashes. So the missing price is not a page that has not caught up with yesterday's launch. OpenAI has kept a Cyber row on its price card for generations and has never put a number in it. We have pulled that thread properly in our GPT-5.6-Cyber pricing breakdown.

For reference, the rest of the family is priced normally, per million tokens on the standard tier:

Note that Terra and Luna both dropped on 30 July 2026, by 20% and 80% respectively. Plenty of coverage still quotes the launch-day figures of $2.50/$15 and $1/$6, which are now wrong. Our GPT-5.6 pricing guide has the current numbers, including the newer short-context and long-context split, and the Sol pricing breakdown digs into the flagship on its own.

If the gate is a dealbreaker and you need capable security tooling now, that is a different question with a real answer. We worked through it in GPT-5.6-Cyber alternatives, and the shortlist is not what most people expect.

What this means if you are not a security team

Most people reading a GPT-5.6-Cyber post will never apply for Daybreak. The transferable lesson is still worth having, because it is the same one we keep relearning at eesel.

The hard part of shipping a capable model was never the capability. It is the control surface around it. Look at what OpenAI actually built here: not one unlocked model, but a tier system, an identity check, a scope definition, an auto-review mode, a monitoring layer, and a hardware key mandate. The model was the easy part.

That is the same reason the AI agent versus chatbot distinction matters more than model choice, and why AI versus human support is rarely settled by benchmark scores.

I recognise that shape from the other side of the table. In three years of putting AI agents on live support queues, I have watched deal after deal turn on the review rather than the demo. A Danish telematics buyer would not let a single ticket through until they were satisfied that data containing card numbers and passwords stayed inside their environment. A Brussels support team of 400 to 500 tickets a month never got past their internal ISO review at all. In none of those conversations was anyone asking whether the AI was smart enough.

That is why we built eesel the way we did. Before an AI agent answers a single real customer, you can simulate it over thousands of your own historical tickets and see exactly what it would have said, then scope it down to the specific ticket types you trust it with. It is the same instinct as Daybreak's sandbox-and-scope guidance, pointed at a support queue instead of a V8 heap.

The parallels keep going. Scoped permissions are how we think about chatbot compliance, logging every action is what makes helpdesk security reviews survivable, and the strictest version of all of this shows up in HIPAA-compliant AI. None of it is about the model.

Try eesel

If you are running a support team rather than a red team, the model tier matters less than what sits around it. eesel plugs into your existing helpdesk, learns from your past tickets and help center, and lets you dry-run the whole thing on historical conversations before it goes anywhere near a customer.

You pick which ticket types it handles and escalate the rest, so there is no flip-the-switch moment. Every tool action the agent takes is logged, and you can gate the sensitive ones behind human approval, which is the support-desk version of auto-review mode. Setup takes minutes rather than a vetting cycle, and it is free to try.