Sakana AI announced enterprise early access for its Sakana API Platform on October 28, 2026, bringing member management, API keys, usage tracking and budget controls into a shared administration system. Access requires an application and individual review; pricing and terms are supplied during onboarding, not published in the announcement. Sakana’s announcement names Fugu and Fugu Ultra as the initial models, with Namazu and Fugu Max to follow.
The change is primarily operational. Sakana previously offered Fugu and Namazu through standalone APIs. The enterprise platform adds a management layer around model access, letting organizations create workspaces for teams or environments and administer their usage centrally.
For developers, the practical question is how much of an existing integration can carry over, and which governance checks still need answering. Sakana’s documentation provides useful detail on both, including an important distinction between managing who can call a model and controlling which underlying providers that model can use.
What Is Available in Enterprise Early Access?
Sakana describes Fugu as an orchestration foundation model that coordinates multiple frontier models for a workload. That makes this an opportunity to evaluate a model-orchestration service through familiar API interfaces, without building the routing system yourself.
The enterprise announcement sets out a narrower initial lineup than the broader console documentation:
| Model | Enterprise platform availability | Documented purpose |
|---|---|---|
| Fugu | Available first | General-purpose orchestration, routing tasks across a model pool |
| Fugu Ultra | Available first | Deeper orchestration aimed at difficult tasks where answer quality takes priority |
| Sakana Namazu | To follow | Japanese-focused language model |
| Fugu Max | To follow | Orchestration aimed at balancing performance and cost |
These descriptions come from Sakana’s announcement and model documentation. They are vendor descriptions, not independent performance findings.
The distinction matters because the general console pages discuss more models than the enterprise launch includes. A model appearing in API documentation is not proof that it is enabled for this early-access program. Teams planning around Namazu or Fugu Max should obtain an availability commitment before making either a project dependency.
Centralized Keys, Workspaces and Spending Controls
The platform groups workspaces beneath an organization. Sakana says customers can configure settings by team or environment and view team usage, with members, API keys and consumption managed through an administration console.
Its announced controls include:
- Role-based access control: permissions based on assigned roles.
- CSV audit-log downloads: exportable records for operational or governance review.
- Budget limits: controls for managing spending.
- Invoice payment: a billing option for enterprise procurement.
- MSA and DPA support: a master services agreement and data processing agreement.
- Contractual input-data protection: terms stating that inputs are not used for training.
Sakana also says more granular organization-level permission controls are planned, so buyers should separate the current role system from promised additions. The announcement does not enumerate the present roles, audit-event coverage or enforcement details for budget limits.
I’d treat budget enforcement as an onboarding question, not a checkbox. A spending threshold is useful, but developers need to know what happens when it is reached: whether new requests stop, how in-flight work is handled and how quickly usage appears in the console. Those details determine whether an application needs its own spending safeguards.
The same applies to audit logs. CSV export gives teams a way to inspect records, but the announcement does not specify which actions are recorded or how long records remain available. Security teams should ask for a sample export and retention policy before designing a compliance workflow around it.
The no-training commitment is concrete and useful. It answers one data-use question; it does not, by itself, answer questions about retention, processing locations or downstream provider handling. Those belong in the contract review.
OpenAI Compatibility Reduces Integration Work
Sakana’s announcement says existing applications can connect by changing their endpoint. Its getting-started documentation supplies the implementation detail: the service is hosted at https://api.sakana.ai, with OpenAI SDK examples using the base URL https://api.sakana.ai/v1.
The documentation lists support for OpenAI-compatible Chat Completions and Responses interfaces, plus an Anthropic-compatible Messages API. Sakana recommends the Responses API for generation requests, particularly workflows involving tools, multimodal input or reasoning management.
For a Python application already using the OpenAI SDK, the connection can look like this:
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["SAKANA_API_KEY"],
base_url="https://api.sakana.ai/v1",
)
result = client.responses.create(
model="fugu-ultra",
input="Explain the security tradeoffs of API key rotation.",
timeout=120.0,
)
print(result.output_text)
This illustrative example follows Sakana’s documented SDK pattern. It reads a Sakana key from an environment variable, sends a Responses API request to fugu-ultra and prints the returned text. The timeout is 120 seconds; it is a client setting, not a promised response time. The code has not been executed for this article.
“Change the endpoint” is therefore a useful shorthand, but a migration also needs the correct Sakana credential and model identifier. Teams should validate streaming, tool calls, error handling and timeout behavior against their actual application. Sakana specifically warns that complex Fugu tasks may require longer client-side timeouts.
Version tracking matters too. The current documentation identifies fugu-ultra as Fugu Ultra v2.0 and lists version-specific model identifiers. For a controlled evaluation, record the identifier used and ask which versions the enterprise program enables.
Unified Credentials Do Not Set Provider Policy
Sakana’s getting-started page says Fugu and Namazu can use the same console-issued API key. That describes credential reuse across model APIs; it does not change Namazu’s later availability in the enterprise rollout. The enterprise platform separately centralizes key administration.
There is another layer beneath those credentials: the model pool used for orchestration.
For standard Fugu, Sakana documents a custom model-pool option when creating or editing an API key. Enabling it lets customers leave selected providers in the routing pool. With that option off, Fugu uses its full default pool. Fugu Ultra, however, uses a fixed pool, according to the . Sakana directs enterprise customers with specific provider or model-configuration requirements to contact the company.
Frequently Asked Questions
3 questions
1Is Sakana API Platform Generally Available?
No. Enterprise access is application-based. Sakana reviews applications and contacts applicants individually before providing pricing and terms.
