Fallback Notice

Preview in your theme

live loop — one retry per event: the button locks the moment it fires, a second overload arms a NEW event (and unlocks it), and the successful retry retires the notice

A vector index is only worth rebuilding when the embedding model changes; re-chunking alone can be applied incrementally.

Answered by a backup model

gpt-4ogpt-4o-mini

gpt-4o was at capacity. The provider shed the request before gpt-4o saw it, so it was re-issued to gpt-4o-mini. Capacity usually returns within a minute — retrying then gets you the primary model's answer.

onRetryPrimary fired 0× · event evt-1 · pressing the locked button again is a no-op; only a new eventId re-arms it.

variant="compact" — one wrapping line for a message footer: the chips carry the names, the reason shrinks to two words, and the same one-shot retry rides along

Yes — pgvector will use the HNSW index for a cosine-distance query, as long as the query and the index share an operator class.

gpt-4ogpt-4o-miniout of quota

onRetryPrimary fired 0×, and it can never go higher here: nothing hands this notice a new event, so the button stays locked on “Retry sent”. Quota is enforced on the provider's side, which is why the copy warns that an early retry spends another request on the same limit.

context_length · onRetryPrimary IS passed and deliberately not rendered — the same request can never fit the primary, so the only exit shrinks the request

Answered by a backup model

gpt-4ogemini-2.5-pro

The request did not fit gpt-4o. It is larger than gpt-4o's context window, so it was routed to gemini-2.5-pro, which has a bigger one. The same request will never fit the primary — it has to get smaller first.

The retry that would fail is not rendered; the exit that helps is.

a chain, not a hop — two models were tried and failed before one answered; provider-qualified ids wrap instead of widening the column

Answered by a backup model

accounts/fireworks/models/llama-v3p1-405b-instructmistral-large-2411command-r-plus-08-2024accounts/fireworks/models/llama-v3p1-70b-instruct

accounts/fireworks/models/llama-v3p1-405b-instruct was unavailable. The provider did not accept the request at all — an incident, a region outage, or a model that has been withdrawn. Nothing was billed on accounts/fireworks/models/llama-v3p1-405b-instruct, and accounts/fireworks/models/llama-v3p1-70b-instruct answered instead.

Provider status

via[] renders muted, dashed chips in order; only the model that answered is highlighted.

dismissible — the notice hides itself and reports it; the dismissal belongs to THIS fallback event, so the next one comes back on its own

Answered by a backup model

claude-sonnet-4claude-haiku-4

claude-sonnet-4 was at capacity. The provider shed the request before claude-sonnet-4 saw it, so it was re-issued to claude-haiku-4. Capacity usually returns within a minute — retrying then gets you the primary model's answer.

re-rendered 0× since the dismissal · event evt-1. Dismiss it, then try both buttons.

in flight (retrying pinned on) — the label names the model being retried, the icon spins where motion is allowed, and the button is aria-disabled rather than disabled so keyboard focus stays put

Answered by a backup model

claude-opus-4claude-haiku-4

claude-opus-4 was unavailable. The provider did not accept the request at all — an incident, a region outage, or a model that has been withdrawn. Nothing was billed on claude-opus-4, and claude-haiku-4 answered instead.

Frozen here on purpose: this state lasts one request in real life.

unsupported — the request needed a capability the primary does not have, so no retry is offered at all and the exit is a docs link

Answered by a backup model

deepseek-v3gemini-2.5-flash

deepseek-v3 cannot handle this request. It needed an attachment type, a tool or a response format deepseek-v3 does not support, so gemini-2.5-flash took it. Retrying changes nothing until the request changes.

Which models see PDFs

retryable comes from the reason class; passing retryable={true} would force the button back for an app that knows better.

product voice — labels, summary and detail rewritten, announce turned off because the surrounding message list already owns a live region, and retryable={false} because this surface cannot re-run the request

This reply came from our standby model

o3o4-mini

o3 took too long, so we did not make you wait. Standby models are cheaper and a little blunter. Long answers are the ones worth double-checking.

Every string is overridable, and the behaviour does not change.

Loading preview…

"use client"

import * as React from "react"
import {
  ArrowRight,
  ArrowUpRight,
  CircleAlert,
  Gauge,
  Puzzle,
  RotateCw,
  Scissors,
  Server,
  ServerCrash,
  TimerOff,

Installation

npx shadcn@latest add https://ui.zyeon.ai/r/fallback-notice.json

Prompt

The prompt behind this component — paste it into your AI assistant to recreate or adapt it.

Build a React + TypeScript + Tailwind "FallbackNotice" component (lucide-react for
icons) that annotates an answer produced by a BACKUP model after the primary one
refused the request. The framing decides everything: a fallback is a failure that
succeeded — the answer exists, so the notice is informational and small, never a
destructive error card.

Contract
- forwardRef<HTMLDivElement>, extends React.HTMLAttributes<HTMLDivElement> minus
  children; spread the rest on the root; merge className with cn().
- primary: string — the model the request was aimed at, which did not answer.
- fallback: string — the model that actually produced the answer.
- reason?: "overloaded" | "unavailable" | "rate_limited" | "timeout" |
  "context_length" | "unsupported" | "unknown" (default "unknown").
- via?: string[] — models tried between the two; every one of them failed too.
- eventId?: string — identity of this fallback event (see the arm key).
- summary?: string — replaces the class summary. Plain string, because the live
  region speaks it.
- detail?: React.ReactNode — replaces the explanation; `false` drops it.
- variant?: "default" | "compact" (default "default").
- retryable?: boolean — force the retry affordance on or off.
- retrying?: boolean — consumer-owned in-flight flag.
- onRetryPrimary?: () => void — re-runs the request on the primary.
- action?: { label; href } | { label; onClick } — ONE extra exit, as a union so a
  button that goes nowhere is a compile error, not a support ticket.
- dismissible?: boolean (defaults to true when onDismiss is passed);
  onDismiss?: () => void.
- announce?: boolean (default true); labels?: Partial<Labels> for every string.

Behavior — the reason class is the input
- Keep one RECIPES table keyed by reason: { short, summary(primary),
  detail(primary, fallback), icon, retryable }. Copy, icon and whether a retry
  exists are looked up, never branched in JSX; adding a reason is one row.
- retryable is FALSE for context_length and unsupported: the same request can
  never fit a smaller context window and can never gain a capability, so a retry
  button there is a button guaranteed to reproduce the fallback. Render the
  `action` exit instead. The `retryable` prop overrides the class either way.
- The retry affordance appears only when onRetryPrimary exists AND the class (or
  the override) says a retry is plausible.
- Suggested copy: capacity — "returns within a minute, retry then"; quota — "an
  early retry spends another request on the same limit"; timeout — "the primary
  may have finished anyway, a retry can be billed twice"; context — "it has to
  get smaller first"; capability — "retrying changes nothing until the request
  changes".

Behavior — one event, one retry
- Derive an arm key from `${eventId}|${reason}|${primary}|${via}|${fallback}`.
  It identifies ONE fallback event.
- Everything that happens once per event is keyed on it: the retry lock, the
  dismissal and the announcement. When it changes, all three re-arm — and the
  re-arm happens DURING RENDER (React's adjust-state pattern: compare with a
  prev-key state), not in an effect, which would paint one frame of the previous
  event's locked button first.
- Pressing retry sets a `fired` state, calls onRetryPrimary once and locks the
  button; the label goes retry → "Retrying with X…" (while `retrying`) →
  "Retry sent". Guard inside the handler and mark the button aria-disabled — do
  NOT use the native disabled attribute: a disabled button leaves the tab order,
  so a keyboard user parked on it loses focus to <body> the instant it locks.
- The consumer decides what a successful retry means: normally it replaces the
  answer and unmounts the notice. If the primary fails again, it hands over a new
  eventId, which unlocks the button for the new event.
- Dismissal is self-service: the component hides itself (returns null) and calls
  onDismiss so the caller can persist the choice. It is scoped to the event —
  any number of re-renders keep it hidden, a new eventId brings it back, because
  the NEXT fallback is news again.

Behavior — screen readers
- One sr-only <span role="status" aria-live="polite" aria-atomic="true">, mounted
  from the first render but EMPTY, filled on the next animation frame (a live
  region that already holds content when it enters the DOM is announced
  unreliably). Cancel the frame on unmount.
- It speaks once per event: "Answered by <fallback>. <summary>". Keep a
  latest-ref of the copy so re-worded labels cannot re-announce a fallback the
  user has already heard; the effect depends on the arm key alone. Wrap the text
  in a node keyed by a counter so identical words re-announce on a new event.
- announce={false} when the surrounding message list already owns a live region.
- The arrows between chips are decorative (aria-hidden); each chip carries an
  sr-only prefix instead — "Primary model, did not answer:", "Also tried, also
  failed:", "Answered by:" — so the hop survives without the glyphs.

Rendering & styling
- Semantic tokens only: bg-muted/40 + border for the notice body (info tone, and
  visibly not the answer's own bg-card), bg-primary/10 + text-primary for the
  reason icon, border-primary/30 + bg-primary/10 for the model that answered,
  border-dashed + bg-muted/60 + text-muted-foreground for every model that did
  not, text-muted-foreground for the explanation, ring for focus. No destructive,
  no hex, no rgb(), no oklch().
- Chips are wrapping boxes with min-w-0 and wrap-anywhere, never nowrap pills: a
  provider-qualified id (accounts/…/llama-v3p1-405b-instruct) must wrap instead
  of widening the message column the notice is annotating.
- variant="default": a small card — icon bubble, headline, chip chain, one
  paragraph (bold summary + muted explanation), then a control row indented to
  the text column. variant="compact": one wrapping line — icon, chain, the
  two-word reason, the same controls, dismiss pushed to the end. Same DOM
  skeleton, same role, same state machine; only density differs.
- Root is role="group" + aria-labelledby the headline (sr-only in compact), with
  data-reason / data-variant / data-state="idle|retrying|sent" for styling hooks.
- Motion: one 220ms fade-and-lift entrance from keyframes shipped in a hoisted
  <style href precedence> element, plus a spinning retry icon while in flight.
  Both are motion-reduce:[animation:none] / motion-reduce:animate-none — with
  animation off, the notice and every label still read exactly the same.

Customization levers
- Reason table: add rows (region_failover, cost_cap, byok_missing) or rewrite the
  copy; each row owns its icon and its retryable verdict, so nothing else moves.
- Density: default vs compact is the main knob; below that, the paddings
  (p-3 / px-2.5 py-1.5) and text-xs / text-sm are the only spacing values.
- Tone: swap bg-muted/40 for bg-card to make it a raised card, or for
  bg-primary/5 to tint it; keep it away from destructive tokens unless your
  product treats a fallback as an incident.
- Chip emphasis: the "answered by" chip is the only highlighted element — flip
  the treatment if you would rather emphasise what failed, or drop the mono font
  for a friendlier read.
- Blocks you can drop: the chain (headline + summary alone still work), the
  explanation (detail={false}), the action, the dismiss button, the live region.
- Chain depth: cap `via` in the consumer if a long chain is noise — showing the
  first hop and "+3 more" is a one-line change in the chain renderer.
- Copy: every string is in one labels object, including the announcement builder,
  so translation and product voice never touch the logic.

Concepts

Degraded but successful — a fallback is the one failure the user is not blocked by, so the notice is info-toned and subordinate to the answer it annotates; treating it like an error card teaches people to dismiss the only line that says "this is not the model you picked".
Reason class recipe — the reason is the single input: it looks up the sentence, the icon and the verdict on whether a retry is worth offering, so a new failure mode is one row in a table instead of another branch in the layout.
Suppressed retry — for a request that overflowed the context window or needed a capability the primary lacks, retrying is guaranteed to reproduce the fallback; the button is not rendered at all and the exit becomes "make the request smaller" or "read which models can".
One-shot lock per event — the retry leaves at most once per fallback event; the button locks on press and only a new event key (a new eventId, a different pair of models, a different reason) unlocks it, so an impatient double-press cannot bill two completions.
Event-scoped dismissal — closing the notice hides this fallback, not the feature: the component keeps it hidden across re-renders of the same event and shows itself again on the next one, because a second fallback is news again.
Quiet announcement — the live region mounts empty and is filled one frame later, speaking "answered by X, because Y" exactly once per event; re-worded labels or a parent re-render never re-announce, and the visible text stands on its own afterwards.

Installation

Prompt

Concepts

On This Page