OperantAI Workflow Design System
ComfortableCompact

/generator turns a text prompt into a working .ods-* snippet. It's a starting point, not a substitute for reading the component docs — always check the validation badges and, for anything consequential, Agent Rules yourself.

Using it

  1. Describe the UI in the prompt box (e.g. "an approval card for a duplicate-charge refund request"), and pick an output mode — HTML or React — from the segmented control in the composer toolbar.
  2. Generate (button, or ⌘/Ctrl+Enter). The response streams in token-by-token; a "Streaming" indicator shows while it's in flight, and Stop (or Esc) cancels the request early.
  3. Once a response completes, it's checked against a set of validation badges — fast, synchronous heuristics that flag the most common design-system violations before you copy anything: no raw hex colors, uses .ods-* classes, and (React mode only) imports only from react/@operant/ui and exports a default component. These are regex-level checks, not a real type-check or a11y audit — they catch obvious drift, not everything in Agent Rules' full checklist.
  4. Copy code, or Open in Playground to keep iterating on the same snippet with a live preview, Monaco editor, and (in HTML mode) a pixel-accurate render.

The right-hand pane renders a live preview of whatever was generated, in the same sandboxed iframe the Playground uses.

Which AI actually answers

The Generator doesn't call a single hardcoded provider — it walks an ordered fallback chain of providers, trying each in turn until one successfully streams back a response. By default the order is Groq → Google Gemini → OpenRouter → OpenAI → Anthropic (configurable on the server via AI_PROVIDER_ORDER), chosen so that the free-tier options are tried first. Only providers with a configured key are attempted at all; if a provider throws before it yields anything (bad key, model unavailable, an outage), the request silently moves on to the next candidate rather than surfacing a half-broken stream. Whichever provider actually answered is shown as a small badge ("via groq", etc.) above the response — useful for knowing which model produced what you're looking at. See Architecture's "AI provider fallback chain" section for the full mechanics (env var names, default models per provider, how the first-chunk check works).

Bring your own key (BYOK)

If no server-side key is configured — or you'd rather use your own — the "Use my own API key" panel (toggled from a button below the composer) lets you paste a key for any of the five supported providers. Each key is stored only in your browser's localStorage and sent as a request header (x-byok-<provider>) on calls to this site's own /api/generate route; it's never logged and never written to any server-side store. That's not the same as "the key never touches a server" — it still passes through this app's own API route on its way to the provider — it's just never persisted there. Treat a pasted key like any other secret kept in browser storage: fine for personal use on a device you trust, not a substitute for real secret management on a shared or public deployment.

If no provider has a key at all — neither a server env var nor a BYOK header — the route returns a clear 503 NO_PROVIDER_CONFIGURED error instead of failing silently.