OpenRouter + OAuth — one key to rule the providers

Status: Candidate — awaiting founder verification. Why this page exists: OpenRouter is the most underrated piece of indie AI infra. This page is the why.

TL;DR

OpenRouter is an aggregator. You hold one credential there, and that credential gives you access to Claude, GPT, Gemini, Llama, and 100+ other models — all through one OpenAI-compatible endpoint. Combined with OAuth, it's also the cleanest user-onboarding flow Apiary has access to. No credit-card flow, no per-provider signup, no key paste. Sign in with OpenRouter, you're done.

Why aggregators exist

Without OpenRouter, switching providers means:

1. Sign up at provider A. Add a card. Get a key. Copy it. 2. Sign up at provider B. Add a card. Get a key. Copy it. 3. Sign up at provider C. Repeat. 4. Now manage three credentials, three billing surfaces, three rate limits.

OpenRouter collapses that to one signup, one card, one key, one billing surface. You add credit once. You access every model.

The tradeoff: a small markup (typically a few percent) on top of the provider's published price. For most users that's worth dodging the signup churn.

What OAuth changes

API keys are great for power users. They're terrible for first-time visitors. The flow looks like:

1. Visit OpenRouter, create an account. 2. Generate a key. 3. Copy it. 4. Paste it into Apiary. 5. Hope you copied the right one.

OAuth replaces all five steps with: click "Sign in with OpenRouter."

The user lands on OpenRouter's signed-in page (if they're not signed in, they sign in there). They click "Authorize Apiary." OpenRouter sends a short-lived token back to Apiary. Apiary uses that token to make calls. No key ever touches the user's clipboard.

PKCE (Proof Key for Code Exchange) is the OAuth flow extension that makes this safe for client-side / public apps — no app secret needed on Apiary's side. Apiary uses OAuth PKCE.

What the user sees

BEFORE OAuth (current default):
  /settings → Provider: OpenRouter
            → API key:    [_________________________]   ← awkward paste
            → Endpoint:   openrouter.ai/api/v1
            → Save

AFTER OAuth (feature-flagged):
  /settings → Provider: OpenRouter
            → [ Connect with OpenRouter ]    ← one click
            → (modal opens, user authorizes, modal closes)
            → ✓ Connected as username@example.com

The OAuth path is feature-flagged off by default in the current Apiary build. Flipping the flag is a single env var. The code is shipped.

Why this matters for Apiary specifically

Apiary is BYO-LLM. The single biggest drop-off in the new-user flow is the moment they realize they need an API key. OAuth dissolves that drop-off:

Visitor → home page → tries chat → "no brain connected yet, pick a provider"
Visitor → /settings → clicks "Connect with OpenRouter" → authorizes → returns
Visitor → chat works

Three steps. No key paste. No card upfront (OpenRouter's free tier covers the first dollar of usage). This is the closest Apiary can get to "zero-friction first chat" without baking in a key — which we won't.

When OpenRouter is the wrong call

Maximum quality. Going direct to Anthropic (or whichever provider) gives you the latest models a few days earlier and no markup.
High volume. At enterprise scale, the OpenRouter markup adds up. Direct contracts with providers win.
Already have credit elsewhere. If you already paid Anthropic, use that key. Don't route through OpenRouter to access Claude.

When OpenRouter is the right call

Trying things. New product, new prototype, want to A/B four models.
Onboarding new users. OAuth flow is dramatically smoother than key paste.
Indie scale. Markup is a few percent. Time saved is hours.
One-credential portability. Move from Anthropic to OpenAI to Llama without re-onboarding.

Source quotes

"OpenRouter: one key, access to Claude, GPT, Gemini, Llama, 100+ others. Pay-as-you-go. Cheaper than going direct to each provider. All OpenAI-compatible endpoints."