OpenRouter API: Base URL, API Key, Free Models and Pricing, Plus a Twitter (X) Agent That Swaps Models

OpenRouter describes itself in its FAQ as "a unified API to access all the major LLM models on the market" that also aggregates billing and usage analytics in one place. Practically, that means three things for a developer: one account and one balance, one API key format (sk-or-...), and one request schema. The API reference says OpenRouter "normalizes the schema across models and providers" and supports two request shapes, the Responses API (POST {base}/responses) and Chat Completions (POST {base}/chat/completions), where {base} is https://openrouter.ai/api/v1.

Each model has a string ID of the form <lab>/<model>, for example anthropic/claude-haiku-5.5 or deepseek/deepseek-v4.1-flash. Suffixes change behavior: the FAQ calls them variants, and :free is the one most people search for, a separate catalog entry with its own price (zero), context length and limits. A few IDs are routers rather than models: openrouter/auto picks a model for your prompt based on what OpenRouter users spend on for that kind of task, and openrouter/free picks a free model for you.

Behind each model ID there can be several providers serving the same weights. OpenRouter's docs say it pools their uptime and retries other providers for the same model when one is rate limiting or at capacity, before an error reaches you. That provider-level failover is automatic; model-level failover (try a different model) is something you opt into with the models array, covered below.

How big is the catalog? It depends on which surface you read. OpenRouter's pricing page advertises 600+ models and 25+ free models; the @OpenRouter bio on X said "400+ models (incl. 50+ free)" when we collected; and the public catalog endpoint (GET {base}/models, no key needed), pulled once in 2026, returned 452 model IDs, 14 of them ending in :free (plus the openrouter/free router and two zero-priced preview models). Treat any count, ours included, as a snapshot and query the catalog in code before you hard-code a model ID.

The base URL is https://openrouter.ai/api/v1. The authentication docs say: if you call the API directly, set the Authorization header to a Bearer token with your key; if you use the OpenAI SDK, point its base URL at https://openrouter.ai/api/v1 and pass the OpenRouter key as the API key. Two optional headers, HTTP-Referer and X-OpenRouter-Title, identify your app for OpenRouter's public rankings; requests work without them. Business and Enterprise accounts that need EU in-region processing use https://eu.openrouter.ai/api/v1 instead.

The three requests below are the fastest way to check a new key: what the key is allowed to spend (and its free-model daily counter), what the catalog currently contains (no key needed), and one chat completion through the free router.

Responses API or Chat Completions? Both work. OpenRouter's newer docs lead with the Responses API, but Chat Completions is the shape most existing code, agent frameworks and the OpenAI SDK's chat.completions.create already speak, so the X agent in this guide uses it. Usage accounting is returned on both without extra parameters; the docs mark the old usage: {include: true} flag on Chat Completions as deprecated and without effect.

Getting the key. Create the key at openrouter.ai/keys after signing in. The authentication docs say you give it a name and a credit limit (or no limit); once a key has used its limit, requests with it are rejected until you raise the limit or, for a daily, weekly or monthly limit, until it resets. Keys created for you during onboarding get a $100 credit limit and expire after 180 days, so a key that suddenly stops working months later may simply have expired.

Use one key per app. Per-key credit limits are the simplest insurance an agent can have: an X digest bot that should spend a few dollars a month gets a key with a small monthly cap, so a runaway loop returns a 403 budget error instead of draining the account. GET {base}/key reports limit, limit_remaining and the budgets that apply, so a long job can check before it starts.

Leaked keys. OpenRouter's docs say it is a GitHub secret scanning partner and emails you when it determines a key was exposed; the fix is to delete the key at openrouter.ai/settings/keys and create a new one. Keep keys in environment variables, never in a repository, and never in client-side JavaScript.

Bring your own key (BYOK). You can also attach your own provider keys and still use OpenRouter's single interface. The FAQ says pay-as-you-go accounts get $25,000 a month of list-price inference through BYOK with no fee, then 5% of what the same model would cost on OpenRouter, deducted from your OpenRouter credits.

Free models are catalog entries whose ID ends in :free. OpenRouter's limits page sets the rules, and they depend only on how many credits you have ever purchased:

The limits page adds that the higher daily ceiling is granted from one credit below the threshold (currently 9 credits) to absorb rounding and top-up fees, that the free_model_daily_requests field of GET {base}/key reports the daily counter, and that the per-minute limit is not reported there. A negative balance can return 402 even on free models; topping up above zero clears it. The FAQ is blunt about the use case: free models "have low rate limits" and "are usually not suitable for production use".

What that means for an X agent. With 50 tweets per request (the batch size we priced below), 50 requests a day is about 2,500 tweets summarized per day; after a 10-credit purchase, 1,000 requests a day is about 50,000. The per-minute cap of 20 is what bites first in a bursty job, so space calls about three seconds apart or back off on 429 as in the snippet below.

The free list moves. In our 2026 catalog pull, the 14 :free IDs were dominated by NVIDIA Nemotron variants (five) and Google Gemma 4 (two), with context windows from 65,536 tokens up to about 1M. Free entries come and go with lab promotions, which is one more reason to keep the model ID in configuration and add openrouter/free as a last fallback. The fallback docs warn that if a :free model is followed by a paid model in models and the request falls through, you are billed at the paid price; to keep a request free, list only :free models.

OpenRouter bills in prepaid credits denominated in US dollars. The FAQ says each model's price is shown per million tokens, usually different for prompt and completion tokens, that some models also charge per request, per image or for reasoning tokens, and that OpenRouter deducts the cost from your credits using the token counts the provider reports. The headline rule is: "there is no markup on inference pricing", but there is a fee when you buy credits.

What the fee does to a real bill. The fee is charged on top-up, not per request, so its effect is a flat 5.5% on whatever you spend on paid models, with an $0.80 floor that makes very small top-ups relatively expensive: a $5 top-up pays the $0.80 minimum (16%), while the 5.5% rate takes over from about $14.55. In the cost table below we multiply model spend by 1.055 to show the effective price.

Plans. The pricing page lists Free (25+ free models, 50 requests a day, no platform fee because nothing is bought), Standard pay-as-you-go (5.5%, rate limits passed through from providers, budgets and prompt caching included), Business pay-as-you-go (8%, adds EU and US in-region routing, workload identity federation and up to 1,000 workspaces) and Enterprise (custom fees, SSO/SAML, contractual SLAs, invoicing).

Reading the real cost of each call. Every response carries a usage object with token counts measured by the model's own tokenizer and a cost in credits, plus cost_details.upstream_inference_cost with what the upstream provider charged. Logging usage.cost per call is the simplest way to reconcile an agent's bill without a second API request.

Set model to your first choice and pass models as an ordered list of fallbacks. OpenRouter's fallback docs say the next model is tried when the current one's providers are down, rate-limited or refuse to reply due to content moderation, and that the request is priced at the model that ultimately answered, returned in the response's model field. With the OpenAI SDK the list goes in extra_body, as in the snippet below.

The three limit families. OpenRouter's limits page separates them by status code. 402 is credits: account balance, a per-key credit cap, or the in-flight spending budget, a temporary hold on the estimated cost of paid requests that are still running, which can reject a request on smaller or newer prepaid accounts even with a positive balance (the error's metadata.limit_source says which, and a Retry-After header appears when waiting helps). 403 is a budget an admin set on the key or workspace, with resets_at telling you when it rolls over. 429 is rate limiting, either OpenRouter's own (free-model caps, DDoS protection) or the upstream provider's, in which case error.metadata.provider_code carries the provider's code.

What to do in code. Retry 429 with exponential backoff and honor Retry-After; treat 403 as "stop until resets_at"; for 402, branch on limit_source rather than the human-readable remedy_hint. If a rate limit hits after a stream has started, the docs say it arrives as an SSE event with finish_reason: "error" instead of an HTTP 429, so streaming agents need to check the last event too.

Aliases. Some docs examples use moving aliases such as ~anthropic/claude-sonnet-latest, which follow the newest model in a family. They are convenient for chat apps and risky for agents whose prompts were tuned on one model; pin a dated ID for anything scheduled and change it deliberately.

To see what builders actually run into, we pulled a de-identified sample of recent public posts that mention OpenRouter (search openrouter -filter:retweets, Latest) and classified them with keyword rules. The sample covered 899 posts from 737 distinct authors over about 46 hours, roughly 19.6 posts an hour; 44.6% were replies, the median post had 1 like and 48.9% had none, so this is everyday developer chatter rather than viral content.

Pricing, credits or cost came up in 27.1% of posts, more than any single model family. Coding agents (Claude Code, Cline, Kilo Code, Roo Code, Cursor, OpenCode, Codex) appeared in 9.8%, routing and fallback talk in 12.7%, API keys in 6.9%, free models in 6.7% and rate limits or errors in 5.9%. Only 1.4% mentioned the base URL or OpenAI compatibility explicitly, which fits the docs' pitch: once the base URL is set, people stop talking about it.

Languages. English was 68.9% of the sample, Chinese 15.6% and Japanese 4.2%, then Portuguese (2.1%) and Spanish (1.1%); 2.9% had no detectable language (links or media only).

What the official account talks about. The 200 most recent posts from @OpenRouter (157,138 followers at collection) spanned 52.9 days, 3.78 posts a day, a third of them reposts. Of its 134 original posts, half (50.0%) announced a model going live on OpenRouter, 20.9% were about routing or platform features (security center, caching, routers), and 9.7% shared usage data such as spend rankings. Only 11.9% of originals mentioned free models at all, yet the two posts our rules classed primarily as free-model news drew a median of 546,110 views, against 18,138 for a typical original post. Free models are what the audience clicks on; launches are what the account mostly posts.

Limits of the sample. Keyword rules miss sarcasm and over-match short words, a 46-hour Latest window reflects the week's launches, and posts that mention OpenRouter are not the same as OpenRouter's user base. The shares are directional; the catalog and limits figures are quoted from OpenRouter's own pages.

The full script is in the code block at the end of this page; here is what it does and why. Step one reads X: GET https://api.twitterapi.io/twitter/tweet/advanced_search with the X-API-Key header, query in X's search syntax and queryType=Latest, following next_cursor while has_next_page is true. Each page holds up to 20 tweets with fields such as text, likeCount, createdAt and author.userName. No X account or X developer app is needed for reads.

Step two builds one prompt per batch of up to 50 tweets and sends it to chat/completions under the OpenRouter base URL with model read from an environment variable and models holding two fallbacks. Changing the model is a config change, not a code change, which is the main reason to put OpenRouter in front of an agent: you can A/B a cheap model against a strong one on the same tweets and compare the outputs and usage.cost side by side.

Step three logs the response's model (which model actually answered, important once fallbacks exist), token counts and cost. A 402 or 429 stops the run with OpenRouter's error object so a scheduler can retry later instead of looping.

Scheduling it. Run the script from cron or a CI schedule. If it polls a query every 5 minutes and usually finds nothing, the X side costs the $0.00015 minimum per empty check, about $1.30 a month; every 60 seconds is 43,200 checks, about $6.48. Only send a batch to the model when new tweets arrived, so the LLM bill tracks volume rather than the clock.

Posting the summary back to X. If the agent should reply or post, TwitterAPI.io's write actions run through an authenticated session: one /twitter/user_login_v2 login ($0.10, with a proxy you supply) returns login_cookies, and each post via /twitter/create_tweet_v2 is then 60 credits ($0.0006), billed per HTTP 200 call. The call acts as that account, so X can rate-limit, lock or suspend it; keep a human pace, and expect the session to need a re-login now and then.

We priced one concrete job, summarizing 1,000 real tweets in batches of 50, using the tweets in our sample. Token counts are an estimate (characters divided by 4 on the real post texts, not a tokenizer run): the median post was 219 characters or about 55 tokens, the mean about 105 tokens. Adding 15 tokens of metadata per tweet, a 200-token instruction per call and 150 output tokens per call gives about 124,214 input and 3,000 output tokens per 1,000 tweets. Prices are the per-token prices in OpenRouter's public catalog at collection, multiplied by 1.055 for the credit fee.

Takeaway. For a summarize-and-report agent, input tokens dominate, and the small fast models make the LLM a rounding error next to the data: on DeepSeek V4.1 Flash or Claude Haiku 5.5 the model added 5 to 10% to the $0.15 data cost. Only frontier-class models (Sonnet 5.5, Grok 4.7) cost more than the tweets themselves. A free variant takes the model cost to zero, within the 50 or 1,000 requests a day described above.

The data side, compared. TwitterAPI.io charges 15 credits per tweet returned, $0.15 per 1,000 tweets, with a 15-credit minimum per request. The official X API's pay-per-usage rate card at docs.x.com/x-api/getting-started/pricing lists $0.005 per post read, $5.00 per 1,000, about 33 times more, with pay-per-usage capped at 3 million post reads a month before Enterprise. Either way, the biggest cost lever in this pipeline is choosing which tweets to fetch, not which model reads them.

Question. What do public posts about OpenRouter talk about, what does the official account post, and what would an X agent spend on the model versus the data?

Accounts and query. The official @OpenRouter timeline (200 most recent posts via /twitter/user/last_tweets; the handle @OpenRouterAI returned "user not found") and a Latest search for openrouter -filter:retweets via /twitter/tweet/advanced_search (899 posts after removing the official account's own posts). OpenRouter's public model catalog (GET {base}/models on https://openrouter.ai/api/v1) was fetched once, without a key, for per-token prices and the :free list.

Window and size. The most recent posts at collection time, collected in 2026: 52.9 days for the account, about 46 hours for the search. 58 API requests in total, about 1,100 tweets, roughly $0.17 of credits.

What it cannot show. Who OpenRouter's users are or how much they spend; keyword shares are approximate; token counts are a characters/4 estimate, and real counts vary by each model's tokenizer; catalog prices change often.

Privacy. Aggregates only. Only the organization account is named; individual authors in the search sample are not profiled, and the published sample rows carry no IDs, handles, URLs or post text.