Operations guide
Sakana Fugu troubleshooting that names the next check
A vague “the API failed” is not a diagnosis. This page turns the documented access, model, region, and billing rules into a short list of checks you can finish before you retry an expensive Ultra or Cyber run.
1. Decide whose problem it is before you retry
Most first failures are local: a missing environment variable, a base URL without /v1, a key from the wrong billing mode, or a model ID that the current key cannot see. Retrying those mistakes on fugu-ultra can duplicate orchestration work. Fail at startup when the configuration is incomplete.
| If you see | Check this first | Do not do this |
|---|---|---|
| 401 or 403 | Key present, active, and matching the intended billing mode | Log the secret or rotate blindly without recording which key was used |
| Model not found | GET /v1/models with the same key and base URL | Silently switch to another model ID |
| EU or EEA users cannot connect | Official product availability, not a client timeout | Proxy around a published regional restriction |
| Cyber missing from the model list | Access approval and pay-as-you-go billing mode | Assume a dated rate table still unlocks the endpoint |
| Bill higher than the visible answer | Orchestration fields and the 272K context threshold | Estimate cost from output length alone |
2. Authentication is not the same as Cyber access
A valid API key can still fail on fugu-cyber. Official Models documentation says Cyber is returned only on pay-as-you-go billing and that users must submit an access request with a use case and verified contact information. A 403 after a successful fugu call is therefore a different class of problem from a missing FUGU_API_KEY.
Confirm three facts separately:
- The process can read
FUGU_API_KEYandFUGU_BASE_URL. - The key’s billing mode is the one you intended. Official docs say Cyber requires pay-as-you-go.
- For Cyber, the access request has been approved. The form is on the official Models page, not on this site.
See the Cyber access guide for the authorized-use boundary and the reason this site no longer publishes a Cyber rate table.
3. Pin the identifier you actually called
The August 17, 2026 Models page lists stable IDs and versioned IDs. fugu-ultra currently defaults to fugu-ultra-v1.1. fugu-ultra-v1.0 is also documented as the former fugu-ultra-20260615. fugu-cyber defaults to fugu-cyber-v1.0. If two environments disagree, compare the Models API output rather than the string in your README.
A team that pinned the dated Ultra alias and a team that uses the moving fugu-ultra name are not running the same configuration. Record the ID returned by the Models API in your run log.
4. Treat EU and EEA unavailability as a product rule
The official product page states that Sakana Fugu is not yet available in the EU or EEA while Sakana AI works toward GDPR and EU-specific compliance. The same FAQ says service is not provided to EU or EEA member states. That is not a timeout you can fix with a larger client deadline.
If your production users are in those regions, stop at architecture. The model chooser returns “unavailable” for this case on purpose.
5. Cost surprises usually come from fields people discard
Official pricing documentation says Ultra reports orchestration input, cached input, and output outside the ordinary input and output totals, and that those fields are real usage. A log that stores only input_tokens and output_tokens will understate a multi-agent run.
Two other official rules cause the same surprise:
- The 272K threshold is per request context, not monthly volume.
- For Ultra,
max_output_tokensapplies to the final model response. The orchestrator still has its own maximum. That field is not a complete spend cap.
Work the numbers with the orchestration token guide or the Ultra calculator. Do not invent a Fugu average or a Cyber rate that the live pricing page no longer publishes.
6. When the request succeeds but the product feels wrong
Temperature or top_p did nothing
Those fields are documented as accepted but ignored. The client is not broken. Remove them from any user-facing “quality” control.
previous_response_id was rejected
Official Responses documentation says the field is not accepted. Send the conversation in input.
You cannot see which worker answered
The product FAQ says routing is proprietary and not exposed. If you must audit every hop, you need a self-managed design, not a different Fugu temperature.
The answer looks complete and is still wrong
Do not retry the same prompt. Save the model ID, prompt, tools, and usage object, then score it with the evaluation playbook.