OpenRouter Fusion Flash API: Status, Setup, and 400 Fixes

Searching for the OpenRouter Fusion Flash API usually means you want the fast Fusion preset or need to fix an HTTP 400. Because the official docs list openrouter/fusion-flash while live discovery may not, verify the alias in your account before integrating.

Is OpenRouter Fusion Flash actually available?

The official Fusion Router documentation lists openrouter/fusion-flash as a separate model slug. It describes the alias as Fusion with the general-fast preset selected by default. That preset is intended for faster, agentic interactions and uses a panel chosen for more homogeneous latency.

The same official guide describes standard Fusion as panel models answering in parallel, an analyst comparing consensus and disagreements, and an outer model writing the final response. Fusion Flash is the faster preset for that compound router, not a single provider model.

The live OpenRouter model catalog retrieved for this guide on September 11, 2026 included openrouter/fusion but did not expose a separate openrouter/fusion-flash record. One user reported the exact symptom on X:

“the docs say openrouter/fusion-flash is a separately listed model with its own /api/v1/models entry, but API calls currently return a 400 error: fusion-flash is not a valid model ID.” — @PeterDaveHello

This is a user report, not an OpenRouter confirmation. OpenRouter’s official documentation describes Fusion, but no official announcement located for this guide confirms a separate Fusion Flash rollout or rollback. The safest conclusion is documented, but verify live availability before integrating.

What to check before diagnosing your code

Run the model catalog request with the same key and environment used by your application:

curl https://openrouter.ai/api/v1/models \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

Search the JSON for the exact string openrouter/fusion-flash. Do not infer availability from a model page, an SDK autocomplete list, or a cached integration. OpenRouter’s models documentation treats the catalog as the source for current model identifiers and supported parameters.

The official status page is also worth checking, but a green platform status does not prove that one router alias is currently usable. The status dashboard reports broad components such as the Chat API and Data API; an alias-specific catalog or configuration mismatch can exist while the general Chat API remains operational.

Minimal OpenRouter Fusion Flash API setup

Start with the smallest possible Chat Completions request. This removes SDK adapters, tool schemas, streaming, and custom Fusion settings from the first test.

export OPENROUTER_API_KEY="your-key"

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/fusion-flash",
    "messages": [
      {
        "role": "user",
        "content": "Reply with the word: ready"
      }
    ],
    "stream": false
  }'

The code shows the endpoint and headers; keep stream: false in the first test so the complete error body is easier to inspect.

If the alias appears in /api/v1/models and this request succeeds, add your application’s fields one at a time. If the alias is absent, do not keep changing prompts or retrying the same request. Test the documented equivalent as a diagnostic:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/fusion",
    "plugins": [
      {"id": "fusion", "preset": "general-fast"}
    ],
    "messages": [
      {"role": "user", "content": "Reply with the word: ready"}
    ],
    "stream": false
  }'

This fallback tests whether the Fusion route and fast preset are reachable, not whether the alias and explicit configuration are identical in every backend detail.

OpenRouter Fusion Flash API 400-error isolation sequence

A 400 generally points to a request or provider rejection; the exact cause depends on the response body. It is different from a 500 outage and from an HTTP 200 response whose inner Fusion operation failed. Use this order so each test answers one question.

1. Read the complete error body

Save the response instead of logging only 400 Bad Request:

curl -i https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"openrouter/fusion-flash","messages":[{"role":"user","content":"ready"}]}'

Look for the error code, message, provider name, request or generation ID, and any metadata. “fusion-flash is not a valid model ID” points to discovery or rollout mismatch. “Provider returned error” points to a request that reached a provider path but was rejected there. A generic 400 without details is a reason to inspect the OpenRouter Activity record rather than to guess.

2. Confirm the exact model ID

Model identifiers are case-sensitive strings. Compare the request with the live /api/v1/models response, including punctuation and the slash. Remove stale aliases from application configuration and avoid silently substituting a guessed Gemini or other Flash model name.

A useful diagnostic matrix is:

3. Remove unsupported fields

Send only model, messages, stream: false, and the two required headers. Then reintroduce fields in this order:

1. temperature or reasoning settings.
2. plugins and the Fusion preset.
3. Custom analysis_models or analyst model.
4. tools and tool_choice.
5. Streaming and framework-specific response options.

OpenRouter’s Fusion guide documents analysis_models, model, preset, max_tool_calls, max_completion_tokens, reasoning, and temperature. A field documented for one endpoint or model family is not automatically valid for every upstream model. The OpenRouter Models reference and the model’s supported-parameter metadata are the right checks.

4. Reduce tool and message-history complexity

Tool-enabled clients can cause confusing 400s because the final payload may contain invalid JSON Schema, an unsupported tool parameter, or an incomplete assistant/tool message sequence. A public Hermes Agent report documented OpenRouter 400 failures in version 0.10.0 with tools enabled across tested models; the report suspected its default 28 tools, but did not include a successful tools-disabled control or a confirmed root cause. Read issue #13927 as a reproduction lead, not proof that every Fusion Flash 400 is caused by tools.

For isolation, try all three of these:

• Send the same prompt with tools removed.
• Send one minimal tool with a simple object schema.
• Start a new conversation without prior tool calls or tool results.

If the minimal text request works and the reduced tool request works, add tools back individually. If a long tool-use history fails while a fresh request succeeds, truncate or summarize the history before investigating the model itself.

5. Separate alias, router, and provider failures

Fusion can involve panel models, an analyst model, and an outer response. A failure in one inner call may not look like a normal single-model failure. OpenRouter’s documentation says to inspect generation and Activity data to see what actually ran. The normal response model field can identify the concrete outer model; it does not by itself prove that Fusion was or was not used.

For a successful Fusion run, the documented generation metadata includes:

{
  "router": "openrouter/fusion"
}

If you supply custom analysis_models, remove them and retest the preset. If the preset works but one custom model fails, the problem is probably tied to that model’s parameters, provider availability, or context limits. If every model fails only through an SDK, compare the raw SDK payload with the working cURL payload. OpenAI-compatible clients may add tools, streaming flags, response formats, or message transformations that are invisible in application-level code.

When to stop retrying

Do not use automatic retries to solve an invalid model ID or a deterministic schema rejection. A 400 marked non-retryable should produce a clear fallback path instead:

• Alias absent from model discovery: route to openrouter/fusion with general-fast, or use a known ordinary model while monitoring the catalog.
• Payload-specific 400: keep the minimal request as a regression test and fix the first field that makes it fail.
• Provider-specific 400: remove the affected panel model or use a configured fallback; record the provider response.
• Broad Chat API incident: check the OpenRouter status page and pause rollout rather than changing application logic.
• HTTP 200 with inner failure: log panel failures and decide whether a partial result is acceptable; do not classify it as an authentication failure.

The official Fusion Router documentation estimates that its default three-model panel costs roughly 4–5 times a single completion; the exact bill depends on the underlying calls. A fallback therefore protects both reliability and spend while the alias is in an uncertain state.

OpenRouter Fusion Flash API FAQ

What is the correct OpenRouter Fusion Flash model ID?

The official documentation lists openrouter/fusion-flash. Verify that exact string in GET /api/v1/models before deployment because documentation and live discovery can temporarily diverge.

Is Fusion Flash a normal fast model?

No. It is documented as Fusion using the general-fast preset. It can still make multiple internal model calls, so “Flash” describes the preset’s latency goal, not single-call execution.

Which endpoint should I use?

Use https://openrouter.ai/api/v1/chat/completions with Bearer authentication and a JSON body. Do not invent a Fusion-specific URL path.

Can I force Fusion to run?

The Fusion documentation supports tool_choice: "required". With Fusion as the only available tool, that effectively forces a tool call. If other tools are present, required means some tool must be called, not necessarily Fusion.

Why can OpenRouter’s status page be green while Fusion Flash returns 400?

The status page reports broad service components. A missing alias, invalid router configuration, or provider-specific rejection can affect one route while the general Chat API remains operational.

Is Fusion Flash free?

Do not assume so. OpenRouter’s Fusion model page explains that the underlying panel and analyst completions contribute to the bill even where the router alias displays no separate token price. Check Activity and the selected model rates before production use.

Use the fast preset only when live discovery and a minimal request agree. Otherwise, fall back to standard Fusion or a known model and preserve the failing payload instead of retrying blindly.