Model Unavailable

What to do when your selected LLM model is unavailable or rate-limited.

Overview

When you select a specific LLM model in Yukkai, the request is routed through OpenRouter to the underlying provider (e.g. Anthropic, Google, OpenAI, or a community-hosted endpoint). Occasionally, the provider may be overloaded, undergoing maintenance, or rate-limiting your account. In these cases, Yukkai reports a Model Unavailable error.

This is almost always transient — the model itself isn't broken, it simply can't process your request at that exact moment. This guide explains what causes the error, how Yukkai responds, and what you can do to get back on track quickly.

How it works

What triggers a Model Unavailable error?

Cause Description
Provider overload The upstream provider is temporarily serving too many requests and cannot accept new ones.
Rate limiting Your OpenRouter API key has exceeded the per-minute or per-day request quota for that model.
Model maintenance The provider has taken the model offline for updates or has deprecated it.
No allowed providers OpenRouter cannot find any enabled provider for the model (e.g. all providers are down or excluded).
Network hiccup A transient network issue between OpenRouter and the provider caused the request to fail.

How Yukkai responds

Yukkai handles unavailable models through a layered strategy:

  1. Automatic retry — When the error is transient (network, brief overload), Yukkai may retry the request after a short delay.
  2. Failover — Where supported, Yukkai can fail over to an alternative compatible model so your task continues without manual intervention.
  3. User prompt — If retries and failover are exhausted or not available, Yukkai asks you to select another model.

💡 Fusion mode eliminates most of these issues: when Fusion is active, each request is automatically routed to a suitable Yukkai-managed model, balancing quality, speed, and cost — so you never depend on a single model's availability.

How to use it

Step 1: Check whether the error is transient

Most Model Unavailable errors resolve themselves within a few minutes. Wait a moment, then try sending the same prompt again. If the error persists, move on to the next step.

Step 2: Check your OpenRouter key usage

If you are rate-limited, you can verify your current usage:

  • Ask Yukkai: "Check my OpenRouter key usage."
  • Yukkai will report your remaining credits, rate limits, and the current billing period.

If you've hit a limit, you may need to upgrade your OpenRouter plan or wait for the rate-limit window to reset.

Step 3: Reduce parallelism

If you are running a Swarm or multiple agents simultaneously, each agent sends independent requests. Too many parallel requests can trigger rate limits even when individual prompts are small.

Recommended actions:

  • Reduce the number of parallel agents.
  • Pause and retry failed tasks individually rather than restarting the entire Swarm.
  • Stagger tasks so they don't all fire at once.

Step 4: Switch models

When a model is persistently unavailable, the fastest fix is to select a different model:

  • Ask Yukkai: "Switch to a different model."
  • Pick from the list of available models Yukkai offers.
  • For general tasks, any high-quality model (e.g. Claude, GPT-4, Gemini) will usually produce similar results.

Step 5: Enable Fusion

If you find yourself frequently switching models due to availability issues, consider enabling Fusion mode:

  • Ask Yukkai: "Turn on Fusion."
  • Fusion automatically selects the best available model for each request, so you never have to worry about individual model downtime.

Examples

Example 1: Transient overload

You: Write a summary of today's meeting notes.
Yukkai: ⚠️ The selected model is temporarily unavailable. Retrying…
Yukkai: ✅ Here's the summary of your meeting notes…

In this case, Yukkai retried automatically and the request succeeded on the second attempt. No action needed from you.

Example 2: Rate limit reached

You: Run a Swarm with 8 agents.
Yukkai: ⚠️ Model unavailable — too many requests. 4 agents completed, 4 failed.

Fix: Reduce the Swarm to 4 agents, or wait a minute and retry only the failed tasks.

Example 3: Model deprecated or down

You: Generate an image using model X.
Yukkai: ⚠️ Model X is unavailable — no allowed providers found for this model.

Fix: Select an alternative model from the available list, or enable Fusion for automatic routing.

Example 4: Switching to Fusion

You: Turn on Fusion.
Yukkai: ✅ Fusion is now active. Requests will be automatically routed to the best available model.
You: Summarize this article.
Yukkai: ✅ (Handled by an automatically selected model)

Tips

  • Wait first. Most Model Unavailable errors clear within 2–5 minutes. A quick retry is often all you need.
  • Keep a fallback model in mind. If your primary model goes down, knowing which alternative you prefer saves time.
  • Use Fusion for hands-off reliability. Fusion is the single most effective way to avoid availability issues because it routes around problems automatically.
  • Monitor your OpenRouter usage. If you frequently hit rate limits, upgrading your plan or reducing parallelism will help.
  • Don't spam retries. Repeatedly sending the same request in quick succession can make rate limiting worse. Space out your retries.
  • Check for provider-wide outages. If multiple models are unavailable at the same time, the issue is likely on the provider's side. Check OpenRouter's status page or wait for resolution.
  • Avoid niche models for critical tasks. Community-hosted or experimental models are more likely to experience downtime. Stick to well-known providers for important work.
  • Retry failed tasks, not the whole batch. In Swarm scenarios, only the tasks that actually failed need to be retried — the completed ones are already done.

Last updated: July 19, 2026