API comparison

Sakana Fugu speaks three API shapes. They are not three identical products.

Official Models documentation now lists OpenAI-compatible Responses and Chat Completions, plus an Anthropic-compatible Messages API. Compatibility describes the request envelope. It does not mean every OpenAI or Anthropic field has the same effect.

Checked August 17, 2026Source: console.sakana.ai/models

1. Pick the shape that matches the work, then stay there

Sakana AI currently recommends the Responses API for generation, especially for tools, multimodal input, reasoning controls, and function calls. Chat Completions exists for code that already speaks that dialect. Messages exists for Anthropic-shaped clients. Switching envelopes mid-project usually costs more than it saves because ignored fields and conversation state differ.

SurfaceUse it whenDocumented caveat
Responses /v1/responsesNew integrations, tools, structured output, streaming with a final objectprevious_response_id is not accepted
Chat Completions /v1/chat/completionsAn existing OpenAI chat client cannot move yettemperature, top_p, penalties, seed, and stop are ignored
Messages /v1/messagesThe caller is already an Anthropic Messages clientRequests are forwarded with standard Messages fields; do not assume every Anthropic-only option is documented here
Models /v1/modelsStartup validationCyber appears only for pay-as-you-go keys with access

2. Model IDs are part of the API contract

As of August 17, 2026 the Models page lists:

  • fugu for the default model
  • fugu-ultra, currently defaulting to fugu-ultra-v1.1
  • fugu-ultra-v1.0, also known as fugu-ultra-20260615
  • fugu-cyber, defaulting to fugu-cyber-v1.0

The same page also lists sakana-namazu as a separate Japanese-specialized model. This library stays focused on Fugu. Namazu pricing and tools are documented on the official pricing page and should not be mixed into a Fugu cost estimate.

3. Accepted-but-ignored fields are a product fact

Teams waste weeks “tuning” a parameter that the server discards. The current Models page is explicit:

  • Responses: temperature and parallel_tool_calls are accepted but ignored. Parallel tool calls are forced on for models that support them.
  • Chat Completions: top_p, stop, seed, frequency_penalty, presence_penalty, and temperature are accepted but ignored.
  • Responses: previous_response_id is not accepted. Send the full history in input.
  • Ultra: max_output_tokens / max_completion_tokens apply to the final model, not the orchestrator’s own limit.
  • Reasoning effort supports high, xhigh, and max. The last two are aliases. Default is xhigh for Ultra and high for Fugu on Responses.
Do not expose ignored fields in a settings UI.

If a user can move a temperature slider, they will believe it changed the answer. That is a misleading representation of the product, even if the API accepted the JSON.

4. Built-in web search is documented, advanced options are not

Official Models documentation says Fugu models support OpenAI-compatible built-in tools on Responses. Adding {"type": "web_search"} is the documented path. It also says advanced options for that tool are not supported. Test citation handling on your own tasks before you treat search as a production dependency.

5. Conversation state is your problem

Because previous_response_id is rejected, a multi-turn app must send the history it wants the model to see. That has two consequences:

  1. Token growth is visible and billable. A hidden server-side thread is not doing that work for you.
  2. You can redact or truncate history on purpose. That is an application decision, not a Fugu feature.

For Ultra, remember that orchestration tokens are extra real usage. A long chat plus a deep route can move a request across the 272K threshold even when the latest user message is short. See orchestration token accounting.

Sources