Sakana AI Fugu‑Cyber: orchestration and verification for security, but buyer beware

Sakana AI Releases Fugu‑Cyber (fugu-cyber‑v1.0), orchestration + verification for security, but buyer beware

On July 21, 2026 Sakana AI launched Fugu‑Cyber (model ID fugu-cyber-v1.0), a cyber‑specialized endpoint built on its Fugu orchestrator. The product pairs an orchestrator-style coordinator with role‑based verification steps: plan, delegate, verify. It is offered only as a hosted API behind application gating and a defensive-use Acceptable Use Policy. Sakana reports strong benchmark numbers, but those results are vendor‑reported and leave important reproducibility and procurement questions unanswered.

What Fugu‑Cyber is, plain language

Fugu‑Cyber is a hosted orchestration endpoint: a coordinator model that breaks security tasks into sub‑tasks, sends them to specialist sub‑agents, and runs a verifier step before returning a result. That “orchestration” pattern, training a model to build temporary agent hierarchies and decide which specialists handle which subtasks, echoes recent research, for example, TRINITY’s Thinker/Worker/Verifier roles and the Conductor’s learned coordination strategies (ICLR 2026). The key shift for buyers is evaluation. You must judge not only raw model quality but the behavior of the whole orchestration chain: who did what, how verification was applied, and whether the outcome is reproducible.

Quick definitions (first time used):

  • Orchestration model: a coordinator that composes and routes sub‑tasks to specialist models.
  • Agentic scaffold: the temporary task hierarchy the orchestrator builds (planner → worker → verifier).
  • Verifier: a sub‑agent that validates outputs (e.g., exploit PoCs or detection rules) before they’re returned.
  • Fan‑out: the average number of sub‑agent calls the orchestrator makes per task.

Commercial terms you need to see early

Sakana sells Fugu‑Cyber only as a hosted endpoint. Key procurement facts:

  • Access is gated, applicants must submit an intended‑use form and pass manual review, and the service enforces a defensive‑use Acceptable Use Policy.
  • There are no downloadable weights or self‑hosting options, “there is nothing to self‑host, quantize, or fine‑tune.”
  • Fugu‑Cyber is not sold in the EU/EEA while Sakana completes GDPR work.
  • Billing is through Sakana’s Token Plan (subscription tiers do not include Fugu‑Cyber by default).

Pricing is published per 1, 000, 000 tokens (per‑1M‑token). At or below a 272K‑token context window, Sakana lists Fugu‑Cyber rates as exactly 1.2× the Fugu‑Ultra rates:

  • Input tokens: $6.00 per 1M input tokens (Fugu‑Ultra: $5.00)
  • Output tokens: $36.00 per 1M output tokens (Fugu‑Ultra: $30.00)
  • Cached input tokens: $0.60 per 1M cached input tokens (Fugu‑Ultra: $0.50)

Cross the 272K context threshold and Sakana doubles those per‑1M rates (so the above become Input $12.00, Output $72.00, Cached input $1.20). Large codebase analyses or long investigation contexts commonly hit that breakpoint, which materially increases cost.

Worked example (simple): a request with 200K input tokens and 50K output tokens at ≤272K context costs:

  • Input: (200, 000 / 1, 000, 000) × $6.00 = $1.20
  • Output: (50, 000 / 1, 000, 000) × $36.00 = $1.80
  • Total ≈ $3.00 for that call (ignoring cached input discounts).

If the same workload crosses the 272K threshold, per‑1M rates double and the cost rises accordingly.

Headline performance, what Sakana reported (and what it really means)

Sakana reports vendor‑measured results of 86.9% on UC Berkeley’s CyberGym and 72.1% on Microsoft’s CTI‑REALM. Tie each number to who reported and what it measures:

  • CyberGym (UC Berkeley): a benchmark of 1, 507 real vulnerabilities across 188 OSS‑Fuzz projects. The task is to produce a proof‑of‑concept (PoC) that crashes a pre‑patch build but not the post‑patch build. Sakana reports 86.9% on this benchmark (vendor‑reported). For context, vendor reports from other organizations place GPT‑5.5‑Cyber at 85.6 (OpenAI, June 2026), GPT‑5.5 at 81.8 (OpenAI, June 2026), Claude Mythos Preview at 83.1 (Anthropic, April 2026), and Claude Opus 4.6 at 66.6 (Anthropic, April 2026).
  • CTI‑REALM (Microsoft): a detection‑engineering benchmark built from 37 public CTI reports (sources include Datadog Security Labs, Palo Alto Networks, Splunk). Tasks include mapping MITRE ATT&CK techniques, probing telemetry, iterating on Kusto Query Language (KQL) queries, and emitting validated Sigma rules across Linux endpoints, Azure Kubernetes Service, and Azure cloud. Sakana reports 72.1 on CTI‑REALM; note that CTI‑REALM uses a 0-1 “trajectory reward, ” so Sakana’s 72.1 should be interpreted as reward 0.721 rather than a literal percent success rate. Microsoft’s reported top three Claude configurations previously scored in the 0.624-0.685 band (March 2026).

Important caveats: these are vendor‑reported figures. Sakana has not published the benchmark harness, the CyberGym level used (CyberGym contains multiple difficulty levels), trial counts or seeding details, or a breakdown of which internal models performed which sub‑tasks. As one secondary summary put it, “Figures are vendor‑reported. Sakana has not published a Fugu‑Cyber harness, level, or trial count.”

“Figures are vendor‑reported. Sakana has not published a Fugu‑Cyber harness, level, or trial count.”, Marktechpost

Why orchestration + verifier matters, and why it complicates procurement

Orchestration adds structure: planning, specialist execution, and verification. For security workflows that require high precision, vulnerability repro, detection‑rule generation, telemetry forensics, a verifier can reduce false positives and risky outputs. That design fits defensive SRE and SOC work better than a single consolidated LLM returning one answer.

But orchestration also raises opacity and operational cost. Key procurement implications:

  • Provenance and auditability: if the orchestrator fans out to several specialists (possibly from different vendors or internal pools), buyers need visibility into which model produced each artifact, how many retries occurred, and what verification checks ran. Sakana has not disclosed that attribution.
  • Latency and token overhead: multiple sub‑agent calls plus verification passes multiply token consumption and wall‑clock time, which can be a problem for SOC workflows that require low P95 latency.
  • Cost per solved instance: fan‑out, retries, cached tokens, and large context windows can materially increase real costs versus headline per‑token pricing.
  • Regulatory and red‑team clarity: Sakana restricts offensive misuse, but buyers should request explicit policy language for authorized red‑team testing and regulatory audits.

What security teams should demand before buying (measurable asks)

Turn marketing claims into procurement‑grade evidence. Ask Sakana for:

  1. Reproducible benchmark runs: run CyberGym and CTI‑REALM with a jointly approved harness. Require N ≥ 10 independent trials per benchmark, share per‑trial logs and random seeds, and expect results within ±3% of the vendor report for the same harness and seeding.
  2. Per‑task model attribution and token accounting: supply a mapping that shows which sub‑agent handled planning, exploit creation, and verification for each run, plus a token breakdown (planner vs worker vs verifier) and cached token usage.
  3. Operational SLAs and metrics: provide P50 and P95 end‑to‑end latency for representative SOC workflows, plus the average and 95th percentile fan‑out multiplier (number of sub‑agent calls per task).
  4. Cost model with worked examples: a 6‑month cost projection for a defined SOC workload (e.g., X investigations/week; median context size Y tokens), including retries and verification overhead and showing cost‑per‑solved‑instance.
  5. Red‑team and compliance carve‑outs: explicit written policy for authorized offensive testing, and a timeline for EU/EEA availability and GDPR compliance.

How to test Fugu‑Cyber quickly, a compact POC plan

If you want a low‑friction evaluation before a major contract, try this lightweight proof‑of‑concept:

  1. Agree a harness and scoring criteria. Use a small CyberGym subset (30 controlled vulnerability instances) and a CTI‑REALM mini‑set (10 CTI reports) with fixed seeds.
  2. Run N = 30 independent trials for the CyberGym subset and N = 10 for CTI‑REALM, capture per‑trial logs, and demand model attribution for each subtask.
  3. Record token consumption and end‑to‑end latency, compute median and P95 fan‑out, and cost per successful instance.
  4. Compare output quality against an in‑house baseline (human SOC analyst or your existing detection pipeline) and check reproducibility of PoCs and Sigma rules.

That POC gives a practical sense of cost, latency, and provenance without a large commitment.

Where this fits in the market

Sakana’s reported CyberGym result (86.9%) sits near recent vendor‑reported frontier scores (OpenAI’s GPT‑5.5‑Cyber at 85.6, GPT‑5.5 at 81.8; Anthropic’s Mythos Preview 83.1; Opus 4.6 66.6), which makes the numbers plausible. But without published harnesses, trial counts, and model attribution, those figures can’t be independently reproduced or audited, and that matters for procurement and regulatory evidence. As one analyst summary put it, “Bottom line: the scores are plausible and roughly in line with the frontier. They are not independently reproducible today.”

“Bottom line: the scores are plausible and roughly in line with the frontier. They are not independently reproducible today.”, Marktechpost

Fugu‑Cyber is an instructive next step: it packages orchestration and verification into a commercial endpoint aimed at security teams. That pattern will likely spread. But orchestration shifts the buyer’s risk profile from raw model accuracy to reproducibility, provenance, and operational cost. Treat vendor‑reported benchmarks as invitations to test, not as procurement proof points.

Key takeaways, quick Q&A

  • What is Fugu‑Cyber and when did it launch?

    Fugu‑Cyber (model ID fugu-cyber-v1.0) is a hosted cyber‑specialized orchestration endpoint from Sakana AI, released July 21, 2026. It decomposes tasks, routes them to specialist sub‑agents, and emphasizes a verifier role to validate outputs.

  • How did Sakana report performance?

    Sakana reports 86.9% on UC Berkeley’s CyberGym (1, 507 vulnerability instances, 188 OSS‑Fuzz projects) and 72.1 on Microsoft’s CTI‑REALM. CTI‑REALM uses a 0-1 trajectory reward metric, so treat the figure as reward 0.721 rather than a literal percent success rate. All these figures are vendor‑reported and lack published harness or trial details.

  • Can I self‑host or get model weights?

    No. Sakana has not published downloadable weights; Fugu‑Cyber is offered only as a hosted endpoint and cannot be self‑hosted, quantized, or fine‑tuned locally.

  • What will it cost?

    Pricing is published per 1M tokens and set at exactly 1.2× Fugu‑Ultra. At or below 272K context: Input $6.00, Output $36.00, Cached input $0.60 per 1M tokens. Crossing the 272K context threshold doubles those per‑1M rates (Input $12.00, Output $72.00, Cached input $1.20).

  • What procurement risks should I be wary of?

    Vendor‑reported benchmarks without shared harnesses or trial counts limit reproducibility; orchestration hides model‑level provenance; fan‑out raises latency and cost; no EU/EEA availability until GDPR work is complete. Ask for reproducible runs, per‑task model attribution, P95 latency, and worked cost examples before relying on reported numbers.