Fugu-Cyber: Benchmarks, Pricing, Access and Deployment Reality

Sakana AI announced Fugu-Cyber on July 21, 2026. Sources reviewed for this guide include Sakana AI's live product, pricing, API, terms, and usage-policy pages, plus documentation from the creators of both benchmarks. The analysis covers what launched, what the scores mean, what access costs, and what a security team should prove before connecting the model to sensitive code, telemetry, or tools.

What Fugu-Cyber is and what launched

Fugu-Cyber is the security-specialized member of Sakana AI's Fugu family. Like the original Fugu system, it behaves like one model from the caller's perspective: an application sends a request to one API endpoint, while an orchestration layer coordinates a pool of specialized agents behind that interface.

Fugu-Cyber is not presented as a newly trained standalone foundation model. It is an orchestration system intended to combine frontier-model capabilities for security analysis, vulnerability research, threat investigation, and other multi-step cyber workflows. Sakana says this reduces single-vendor dependency, although the service still creates one operational dependency on Sakana's routing, availability, policies, and external-model relationships.

For a broader explanation of coordinator, worker, and handoff patterns, see AgentPedia's multi-agent orchestration guide. Those general patterns are useful context, but Sakana has not disclosed Fugu-Cyber's exact worker models, agent count, topology, prompts, retries, or compute budget.

The launch adds three concrete pieces to the existing Fugu offering:

Sakana's Terms of Service describe the broader Fugu service as dynamically routing input to one or more external machine-learning models, including providers such as OpenAI, Anthropic, and Google, sequentially or in parallel. Organizations handling proprietary code or incident data should therefore treat provider routing, retention, regional processing, and contractual controls as architecture questions—not fine print to review after a pilot.

The reported CyberGym and CTI-REALM results

Sakana AI's official launch chart reports the following values:

The chart labels the CyberGym baseline GPT-5.5-Cyber and the CTI-REALM baseline GPT-5.5. It labels both Anthropic comparisons Mythos Preview. Preserving those labels matters because similarly named model variants cannot be assumed to share the same tools, system prompts, reasoning settings, or security specialization.

These are Sakana AI-reported launch results. AgentPedia did not receive gated API access, run the benchmark harnesses, or reproduce the scores. The chart's vertical axis says “Score”; Sakana's launch prose uses “success rate” for both values. CyberGym does define a success rate, while CTI-REALM uses a normalized reward that combines final output and trajectory checkpoints. Treating the two numbers as identical kinds of percentage would hide an important methodological difference.

The chart is useful evidence of Sakana's claim, not a complete model card. The public launch material reviewed for this article does not specify the exact task subset, number of trials, agent scaffold, tool configuration, token budget, wall-clock budget, cost, failure policy, or confidence interval behind Fugu-Cyber's runs.

At the July 21 research cutoff, Fugu-Cyber was not listed on CyberGym's native leaderboard. The leaderboard's one-trial view showed the Crystalline agent system at 89.6 and Microsoft's MDASH multi-model system at 88.4, both above Sakana's reported 86.9. Sakana's chart instead compares Fugu-Cyber with GPT-5.5-Cyber and Mythos Preview. Fugu-Cyber led the comparison runs shown by Sakana; the available evidence does not establish an independently verified, unrestricted system-level record.

What CyberGym measures

CyberGym is a real-world vulnerability-reproduction benchmark built from vulnerabilities found and patched across open-source projects. Its broader dataset contains 1,507 instances across 188 software projects, derived from OSS-Fuzz findings.

In the primary Level 1 task, an agent receives:

• a text description of a known vulnerability;
• the corresponding codebase at an unpatched revision;
• an environment in which it can inspect code and execute candidate tests.

The agent must produce a proof-of-concept input or test that triggers the target failure on the vulnerable revision but not on the patched revision. That is harder and more operational than answering vulnerability trivia: the agent has to navigate a large repository, locate relevant paths, construct an input, observe execution feedback, and refine the result.

CyberGym's leaderboard definition also adds a detail that headline scores can obscure: an instance counts as solved if any permitted trial succeeds. Trial count, step budget, tools, and compute budget can therefore materially affect comparisons. A procurement team should ask whether every compared system used the same task set and trial policy.

A strong CyberGym result suggests useful capability in known-vulnerability reproduction. It does not by itself prove that the system can safely discover unknown vulnerabilities in a live estate, prioritize business risk, avoid destabilizing systems, propose correct patches, or operate without expert supervision.

What CTI-REALM measures

CTI-REALM evaluates a different defensive workflow: turning cyber-threat intelligence into working detection logic.

Microsoft's benchmark gives agents access to public threat reports, schema exploration, telemetry, a Kusto query environment, MITRE ATT&CK references, and Sigma-rule resources. Agents must work through an end-to-end detection-engineering path:

1. identify the relevant threat intelligence;
2. map techniques and select the right data sources;
3. construct and refine KQL queries;
4. produce Sigma rules and executable detection logic;
5. validate those detections against ground-truth telemetry.

The evaluation includes Linux endpoints, Azure Kubernetes Service, and Azure cloud infrastructure. Microsoft describes CTI-REALM-50 as 50 tasks spanning those platforms and scores both final detection quality and intermediate trajectory checkpoints. That is why the benchmark is better understood as normalized workflow reward than a simple pass rate.

The benchmark creators' own results show why one aggregate number needs context. Their published analysis found cloud detection harder than Linux and reported that CTI-specific tools improved model performance. In other words, the surrounding harness is part of the evaluated system. A Fugu-Cyber pilot should measure the exact tools, schemas, data sources, and review process it will use in production rather than assuming the launch score transfers automatically.

What the benchmark scores do not prove

Sakana AI's launch article makes a useful point that marketing summaries often omit: a capable cyber API is one part of a security system, not the whole system.

Benchmark leadership does not establish any of the following on its own:

• low false-positive rates on your code and telemetry;
• correct prioritization by exploitability or business impact;
• safe autonomous tool use;
• reliable patch generation and regression behavior;
• resistance to prompt injection in repositories, tickets, logs, or threat reports;
• reproducibility across model-pool updates;
• acceptable latency and cost under incident load;
• compliance with your data residency, retention, and provider policies.

These risks are not unique to Fugu-Cyber. AgentPedia's agent security guide covers the permission, prompt-injection, and tool-execution boundaries that any model-connected security workflow should test.

Sakana explicitly warns that raw models deployed in isolation will generate false positives and lack the nuances of a live production environment. Its proposed production pattern combines localized security expertise, specialized verification sub-agents, and human-in-the-loop confirmation before a finding drives remediation.

A product evaluation should therefore go beyond “Can it find something?” Reviewers need to determine whether the finding is real, whether the evidence is sufficient, whether the proposed action is safe, and whether a qualified person can inspect the full chain of reasoning and tool activity.

Access, pricing and API status

Fugu-Cyber is not an unrestricted public endpoint. The July 21 launch page says users must submit an access request describing the intended use case and provide verified contact information. Sakana says applications are manually reviewed before access is granted.

The live pricing page lists the model ID as fugu-cyber-v1.0 and says it is available only through pay-as-you-go billing:

These are the listed rates at the July 21 research cutoff, not a lifetime price guarantee. The launch page calls this the “Token Plan,” while the current pricing page calls it pay-as-you-go billing.

Sakana's Fugu API is OpenAI-compatible and supports Responses, Chat Completions, and Models endpoints for the documented Fugu family. However, the live models documentation reviewed at launch still listed fugu, fugu-ultra, and fugu-ultra-20260615 in its supported-model table and had not yet added fugu-cyber-v1.0. The pricing page and launch page do list Fugu-Cyber. Treat that as launch-day documentation lag and confirm the enabled model IDs with /v1/models after approval rather than copying an unverified request into production.

Regional eligibility also matters. Sakana's current Terms exclude users in the EU, EEA, United Kingdom, and Switzerland, while the product FAQ mentions the EU and EEA and notes that access elsewhere may vary with regulation and network conditions. Use the stricter Terms wording and confirm eligibility for the contracting entity and processing location before sending security data.

Usage policy, authorization and safe scope

The Sakana Fugu Usage Policy, effective June 12, 2026 at the cutoff, prohibits unauthorized access to or alteration and destruction of another party's systems, networks, data, or assets. It also prohibits bypassing technical controls.

During legitimate security evaluation, the policy requires Sakana AI's advance written approval for testing, verification, security evaluation, or other experimental activities. The product-access approval described on the launch page should not be assumed to replace that separate policy requirement. Teams should obtain a clear written scope covering the model evaluation and every target environment.

The Terms also say inputs can be routed to external model providers, warn against submitting personal, sensitive, confidential, trade-secret, or third-party protected information, and allow content to be used for Sakana training unless the user opts out. The opt-out is not retroactive. A security-code pilot therefore needs provider mapping, retention terms, a training opt-out decision, and legal approval before proprietary source or incident evidence enters the service.

A safe pilot should use:

• isolated repositories and telemetry you are authorized to process;
• disposable sandboxes with no route to unrelated production assets;
• least-privilege, short-lived tool credentials;
• complete prompt, response, tool-call, and reviewer logs;
• human approval before execution, disclosure, ticket closure, or code changes;
• an incident stop condition and credential-revocation path.

Do not place real secrets in prompts or screenshots. If a test needs realistic credentials or telemetry, use synthetic values and document which production properties the substitute does and does not represent.

A defensible enterprise evaluation plan

A useful evaluation measures the whole socio-technical system: model, orchestration, tools, data, reviewers, and recovery controls.

For implementation-level context on handoffs, guardrails, and tracing, compare the pilot design with AgentPedia's OpenAI Agents Python guide. The goal is not to copy that SDK, but to make orchestration boundaries and audit evidence equally explicit.

1. Freeze the evaluation configuration

Record the Fugu-Cyber model ID, date, API endpoint, reasoning settings, available tools, target repositories, benchmark commit, trial count, step and token budgets, timeouts, and pricing. If the routed model pool is not exposed, ask Sakana how changes are communicated and how customers can reproduce an earlier result.

2. Separate two defensive workstreams

Use at least one vulnerability-reproduction track and one detection-engineering track. For each, include representative easy, medium, and hard cases from your own environment plus a public benchmark slice. Do not combine the outcomes into one vague “cyber score.”

3. Score evidence, not confidence

For vulnerability findings, require a minimal reproducer, affected revision, patched comparison, logs, environmental assumptions, and independent verifier. For detection rules, require the source report, technique mapping, data-source rationale, executable query, ground-truth evaluation, false-positive sample, and reviewer decision.

4. Measure the failure modes

Track false positives, false negatives, duplicate findings, invalid queries, hallucinated files or schemas, unsafe tool requests, prompt-injection compliance, reviewer time, and correction rate. A system that produces more findings but doubles expert review time may not improve the operation.

5. Test control boundaries

Prove that the model cannot access an unapproved repository, secret, tenant, or telemetry table. Inject hostile instructions into code comments, issue text, logs, and threat reports. The expected result is that untrusted content cannot expand permissions or rewrite the evaluation goal.

6. Keep human gates consequential

Human review should not be a ceremonial click. Reviewers need the source evidence, tool trace, proposed action, expected impact, rollback plan, and a way to reject or request more evidence. High-risk actions should remain unavailable to the model, not merely discouraged in a prompt.

7. Compare cost per accepted outcome

Token price is only one component. Measure orchestration tokens, retries, tool compute, sandbox cost, elapsed time, analyst review, false-positive investigation, and remediation rework. Compare cost per accepted verified finding or deployed validated detection, not cost per generated answer.

Who should test Fugu-Cyber now?

Request a controlled pilot if your team already has mature vulnerability-management or detection-engineering workflows, qualified reviewers, isolated test infrastructure, and a clear way to measure accepted outcomes. Fugu-Cyber's launch results make it a credible system to evaluate alongside specialized frontier models.

Wait for more evidence if you need a public reproducibility package, detailed run configuration, stable versioning guarantees, independent benchmark results, or established operational references before procurement.

Do not deploy it autonomously if the workflow can touch production systems, execute untrusted code, publish findings, change detections, or patch software without meaningful expert review and rollback controls.

Fugu-Cyber's most interesting claim is not that one model has solved cybersecurity. It is that orchestration can make several specialized agents perform like one stronger defensive system. The benchmark numbers support testing that hypothesis. The launch material—and Sakana AI's own caveats—do not support skipping the engineering and human controls needed to make it reliable.

Official sources

• Sakana AI Fugu-Cyber launch article and official X announcement
• Sakana Fugu product page
• Sakana Fugu model and API documentation, getting-started guide, and pricing
• Sakana Fugu Terms of Service and Usage Policy
• CyberGym benchmark site, repository, and paper
• Microsoft Research CTI-REALM page, Microsoft Security explanation, and paper