Navin
All documentation

How to Configure Model Fallback in Navin

Model fallback lets Navin try a primary model first, then fall back to one or more named configurations when the primary provider fails or rate-limits.

What you will build

  • two or more model configurations in Settings → Models
  • one active (primary) configuration
  • an ordered fallback list

When to use this

Use fallback when you want better reliability across rate limits, provider outages, local model downtime, or cost-sensitive routing.

Configure in Settings

  1. Open Navin and add credentials under Settings → Providers for each provider you will use.
  2. Open Settings → Models and create at least two configurations (for example Fast and Deep).
  3. Set the everyday configuration as Active.
  4. Open the fallback list for agent defaults (same Models area) and add the backup configuration names in order.
  5. Send a chat message. If the primary provider fails in a retryable way, Navin tries the next named configuration.

Verify each provider works on its own (switch Active temporarily and chat) before adding it as a fallback.

Advanced JSON shape (optional)

{
  "modelPresets": {
    "fast": {
      "label": "Fast",
      "provider": "primary-provider",
      "model": "primary-model-id",
      "maxTokens": 4096,
      "contextWindowTokens": 65536,
      "temperature": 0.1
    },
    "deep": {
      "label": "Deep",
      "provider": "fallback-provider",
      "model": "fallback-model-id",
      "maxTokens": 4096,
      "contextWindowTokens": 200000,
      "temperature": 0.1
    }
  },
  "agents": {
    "defaults": {
      "modelPreset": "fast",
      "fallbackModels": ["deep"]
    }
  }
}

String entries in the fallback list are configuration names, not raw model IDs. Replace placeholder model IDs with IDs from your provider. The Provider Cookbook has concrete Settings recipes.

Production notes

  • Keep fallback context windows realistic; smaller fallback windows constrain how much context can fit.
  • Put cheaper or faster fallbacks before expensive ones when acceptable.
  • Use /model <name> in chat for runtime switching without editing Settings permanently.
  • Keep labels human-readable in the Models list.

Security notes

  • Different providers may have different data handling policies.
  • Do not put provider keys in shared documents.
  • Confirm fallback models can safely receive the same prompts and files.

Troubleshooting

  • Fallback never triggers: confirm the primary error is treated as retryable.
  • Startup / save fails: check that each fallback name matches a configuration under Models.
  • Output truncated after fallback: review max tokens and context window on the fallback configuration.

Related docs