OrcaCyber Zero 1.5 vs OrcaCyber Zero 1.0: what changed, what didn't, and what the numbers cover

Twenty-three days separate the two model pages, and the diff is shorter than the launch post implies. OrcaCyber Zero 1.5 went live on OrcaRouter on 10 October 2026 as the successor to OrcaCyber Zero 1.0, announced with updated weights and a fresh set of benchmark results. The weights may well be new. The commercial terms are not: input price, output price, cache-read price, context window, output ceiling, capability flags and access tier are identical between the two generations, to the last decimal. What moved is the evidence — four published benchmark rows where there used to be one, and a latency panel now measured over three days instead of seven. Both generations answer on the same OpenAI-compatible endpoint, so the comparison costs one model id. A model's own numbers say nothing about what an agent built on it does once it is running — that record is kept separately, in the AI incident archive.

The fields that did not move

Start here, because a successor release invites the assumption that they did.

• Price — $3.00 per 1M input tokens, $7.50 per 1M output, $0.75 per 1M cached input. Identical on both pages, and unchanged since Zero 1.0 shipped on 17 September.

• Context window and output ceiling — 1,000,000 tokens in, 128,000 tokens out. Identical, and both figures are unchanged from the earlier model.

• Capability flags — `tools`, `json`, `reasoning`. Identical, in the same order.

• Access — tier `sec-uncensored`, band `offensive`, `locked: true`. Identical, and still the strictest gate on the platform.

That is the whole of the successor's commercial surface, and none of it moved. If what you were waiting on was a cheaper token, a longer context or an easier way in, none of those arrived.

The benchmark rows are where the release actually lives

Zero 1.0's page lists exactly one benchmark row: CyberGym Level 1 pass@1, 98.07%, evaluated 17 September. Zero 1.5's page lists four, all dated 10 October:

• Cybench — 100%, with the parenthetical qualifier "unrestricted agent execution."

• CVE-Bench — 95.8%, and the benchmark name itself carries the narrowing: "CVE-Bench (evaluable subset)."

• HumanEval+ — 93.9%.

• SWE-bench Pro V2 — 76.5%, the lowest of the four and the only software-engineering rather than security score in the set.

Every one of those five rows across both generations — the four here and the CyberGym line on Zero 1.0 — was produced by us, and each row says so: the four new ones carry source: "orca", the older one source: "orcarouter". There is no third-party row on either page, and no row whose evaluation date is anything other than the day that generation launched. That matters before any of the percentages get quoted elsewhere, because a benchmark list with no source column reads as though the numbers arrived from somewhere neutral. These did not.

What the launch post carried, and what it left out

The announcement itself is short. Its link card does the selling: "Drop-in OrcaCyber Zero 1.5 API for any OpenAI SDK — $3.00 / $7.50 per 1M tokens, p50 2947ms via OrcaRouter. Zero markup. Zero migration. One API."

That 2947 ms is not the number on the model page today. The page reports a p50 of 3220 ms. Both are ours, both are honest, and the gap between them is the reason the next section exists: there are more latency figures in circulation for this model than there are measurements behind them.

Three latency numbers for one model

• 2947 ms p50 — in the launch post's link card.

• 3220 ms p50, 9656 ms p95 — on the model page, aggregated over the days currently in its window.

• 500 ms p50, 2.36 s p95 — reported by one write-up as time-to-first-token over seven days, from a sample it describes as small, on the order of 1.3K tokens of traffic.

These are three different quantities measured at three different times over three different volumes. The card's figure is a snapshot. The page's figure is a rolling aggregate that changes daily. The third is time-to-first-token, which is the delay before the first token appears and not the time taken to finish a response — a much friendlier measurement, and not the same thing at all. Quote any of the three without its qualifier and you have invented a fourth.

Three days of data under a seven-day label

Both pages label their latency block window_days: 7, and both name the same source: orcarouter-playground, our own measurement rig rather than a vendor claim. But Zero 1.5's daily array holds three entries — 10, 11 and 12 October — while Zero 1.0's holds seven. A seven-day label over a three-day sample is not a lie; it is a window that has not filled yet, and everything downstream of it inherits the thinner base.

• p50 — 3220 ms now, against 3691 ms for Zero 1.0. Zero 1.0's aggregate rests on roughly twice the traffic: 6.16 billion tokens over seven days against 3.52 billion over three.

• Output throughput — 75.69 tokens per second against 43.75. The largest single change in the whole diff, and the one most likely to be felt in an agentic loop that makes dozens of calls per investigation.

• Error rate — 0.13% against 1.20%, close to an order of magnitude better.

• Uptime — no figure exists. percent_24h reads 0 and the block carries has_data: false, which means the percentage was never computed rather than that the service was down. Both generations are the same here, so nothing can be read into the difference.

What the daily arrays add is a direction, and the two point opposite ways:

• Zero 1.0, seven days — 3663, 4614, 3408, 3729, 3791, 2152, 1946 ms. The two best days are the two most recent.

• Zero 1.5, three days — 2965, 3289, 3416 ms. The worst day is the most recent, and its p95 has already touched the 10000 ms ceiling.

Three points is not a trend, and a launch week is the worst possible sample to generalise from: traffic is unrepresentative, the model is being exercised by everyone who has just been handed access, and caches are cold. The honest reading of the panel as it stands is that Zero 1.5 is faster than Zero 1.0 on the aggregate and slower on each day since it launched. The second half of that sentence would be unfair to say after seven days and is under-supported after three. Watch the number; do not act on it.

100% on Cybench is 100% of what

Four percentages, four different qualifiers, and the qualifiers are where the meaning lives.

• Cybench — the row says "unrestricted agent execution", which describes how the evaluation was configured, not what a paying account is permitted to do. The benchmark is built around professional capture-the-flag tasks, and one write-up reads the 100% as 39 of the 40 tasks it contains. Completing a CTF task is also a different achievement from finding a vulnerability nobody has published a solution for.

• CVE-Bench — the row says "evaluable subset", and the launch post supplies the denominator: 23 of 24. The benchmark is built on a set of critical-severity web CVEs, so a subset score moves when the excluded tasks move, and the exclusion criteria are not published.

• SWE-bench Pro V2 — 76.5%, and specifically not comparable with other SWE-bench variants. That distinction disappears the moment the number is set beside a plain SWE-bench result, which is what usually happens to it.

• HumanEval+ — 93.9%, and the one row with no unusual qualifier attached.

The 98% belongs to the harness, not the model

The figure most likely to be quoted alongside Zero 1.5 is 98.07%, and it is not Zero 1.5's. It is Zero 1.0's CyberGym Level 1 result, and Zero 1.0's own page describes that model as "the frontier-tier model in the OrcaCyber Harness" — which is to say the reported score is a property of the harness: the model plus its memory, its verification stages and its execution environment, not the model on its own. Read the two benchmark tables as one progression and you will conclude that 98.07 became 100. Those are two different benchmarks run by two different configurations of two different generations.

There is a smaller discrepancy worth flagging while we are on the subject. One write-up puts the CyberGym run at 1,477 of 1,507 tasks and 98.01%; our page puts it at 1,478 of 1,507 and 98.07%. Both fractions are internally consistent, and we have not reconciled the third decimal here. Treat it as unsettled rather than picking whichever reads better.

The price held, and that is the interesting part

• $3.00 / $7.50 / $0.75 per 1M tokens, unchanged across the release.

• **On OrcaRouter pricing, the provider's list price is passed through with nothing added** — 0% markup. A vendor price change therefore lands on our side the same day rather than after a repricing cycle, and a single endpoint with one key and one bill is where the spend across several models gets reconciled.

• Token price is the launch's strongest commercial argument, standing against what comparably gated security models are reported to charge — an order of magnitude more, in at least one case, for a model with no published token price at all.

• The unit that decides a purchase is not the token. A security investigation runs dozens of model calls, re-reads the same repository, calls external tools and revises its conclusions before a finding is accepted, so cached input at a quarter of the input rate matters more here than in a chat workload. What a buyer should measure is cost per validated finding, which is not a number either model page publishes.

The gate did not change either

Access still runs through the Security Research tier: tier sec-uncensored, band offensive, locked: true. The published process asks for the engagement, a passkey and accepted terms, which is a gate on purpose rather than on capability — vulnerability reproduction and penetration testing are the same operations whether or not the target has agreed to them.

One line from the launch coverage is worth repeating because it is the part that survives the launch: model-level restrictions and API access controls do not replace application-level authorization. A security agent should not inherit permission to modify systems, read production data or execute sensitive operations merely because the model underneath it can reason about those operations. The tier decides who may hold the key. It does not decide what the key may touch.

What is still missing, including from our own page

• Zero 1.5 has no tagline, no overview and no use cases. All three fields are populated on Zero 1.0 — a full tagline, an overview that names the harness and the CyberGym figure, and four worked use cases. The successor's page carries a longer long_description (791 characters against 626) and that is the entire text, which opens with the literal header "Vendor-reported evaluations:". To the extent the page describes itself, it describes its own numbers.

• No parameter count, no architecture, no training-data composition — true of both generations, and the reason two percentages from two benchmarks cannot be attributed to a model versus a scaffold.

• No technical report for 1.5. Zero 1.0 had one, which is where its harness framing was explained.

• No independent replication of any figure on either page.

• Zero mentions. The Hacker News sentiment block reads mentions_7d: 0 and mentions_prev_7d: 0 for both models. For a frontier security release that is itself a signal, and it points at the gate rather than at the model: a model most people cannot call does not get discussed.

Who should move, and who should wait

If you already hold Security Research access and you are running Zero 1.0, there is nothing to renegotiate and no migration to schedule: same endpoint, same price, same request shape, so the switch is one model id. The measured throughput and error-rate improvements are the reason to try it, and they come from our own measurement rig rather than from a benchmark run by the model's own team, which means you can check them against your own traffic instead of taking them on faith.

If you do not hold the tier, this release does not change your position by a single token — the gate, the price and the context window are all exactly where they were.

The thing to wait on is the latency panel. Zero 1.5 is faster than its predecessor on three days of data and slower on every one of those three days in sequence, and the seven-day window that would settle which of those two facts is the real one has not closed yet. Re-read the page next week. If the daily p50 is still climbing past 3416 ms, the aggregate number on the card is the one that was wrong.