Configuration contract
Pin the Sakana Fugu ID you actually called
On August 17, 2026 the official Models page listed both moving aliases and versioned IDs. Two environments that both say “we use Ultra” can still be running different products. That is a deployment bug, not a quality complaint.
1. The IDs the Models page listed
| ID | What official docs said | When to use it |
|---|---|---|
fugu | Default model | Everyday work; pool exclusions allowed |
fugu-ultra | Defaults to fugu-ultra-v1.1 | Accept alias movement |
fugu-ultra-v1.1 | Current Ultra version | Pin today’s Ultra without the moving alias |
fugu-ultra-v1.0 | Also known as fugu-ultra-20260615 | Reproduce an older Ultra |
fugu-cyber | Defaults to fugu-cyber-v1.0 | Only after access and pay-as-you-go |
The same page also lists sakana-namazu. Do not fold Namazu rates into a Fugu estimate.
2. Startup should ask the Models API
Call GET /v1/models with the same key and base URL you will use for generation. Fail startup if the intended ID is missing. Do not silently swap to another ID. Cyber is documented as appearing only for eligible pay-as-you-go keys, so a missing Cyber row is often access or billing mode, not a typo. See troubleshooting.
3. What to store in the run log
- The ID you requested
- The ID the Models API listed for that key
- Billing mode, if you know it
- The full usage object for Ultra
Without those four fields, later “Ultra got worse” reports cannot be investigated. Alias drift and an orchestration-token surprise look the same in a screenshot of the final answer.
4. A conservative default
Use the moving alias in prototypes. Pin a versioned ID in any comparison you might publish internally. If two teams disagree, compare Models API output before comparing answers. Copyable client setup lives in the API quickstart.
5. Failure modes that look like model quality
Team A pins fugu-ultra-v1.0. Team B uses the moving alias and quietly receives v1.1. They run the same prompt. The answers differ. Both groups blame “Ultra.” The log that would have settled it is the Models API list from that morning.
A second failure mode is Cyber. The ID is correct in the README, the key can call fugu, and /v1/models omits Cyber because billing mode or access is wrong. Retrying generation does not add the ID to the list. See Cyber access.
A third failure mode is partner routes. A listed partner may expose only fugu-ultra and not the versioned IDs. You cannot pin what the partner does not list. Compare catalogs before you promise reproducibility. See third-party access.
Official product FAQ also says Fugu aims to absorb new public frontier models after roughly two weeks of training and evaluation. Alias movement is therefore an expected event, not an outage. Pin when you need a frozen comparison. Ride the alias when you want the vendor’s current default and you are willing to re-run evaluation after a change.
Write the pinning rule in the same place you write the region rule. “We accept alias movement in staging. We pin versioned Ultra IDs in any numbered experiment.” A rule that lives only in Slack will not survive the next hire. The glossary entry for Models API exists so this sentence can stay short in other articles.