OpenRouter model slug reference for probes

Photo by bigworldinalens from Pexels

When you're monitoring LLM API latency across 21 regions, precision matters. OpenRouter exposes hundreds of model endpoints, each with its own slug identifier, and choosing the right models to probe is critical to catching regional degradation before your users notice. This resource walks you through OpenRouter's model slug system, how to reference models in Observinio probes, and how to build a comprehensive monitoring strategy around the models your application actually depends on.

TL;DR

• OpenRouter model slugs are unique identifiers (e.g., openai/gpt-4, anthropic/claude-3-opus) used to specify which model a probe should test.
• Use the OpenRouter models API endpoint or the /docs/llms.txt file to fetch the complete, up-to-date list of available slugs.
• Observinio probes can target any OpenRouter slug; track latency (TTFB, TTFT) and availability per model across all 21 regions.
• Baseline probes for your most-used models (e.g., GPT-4, Claude 3) establish regional variance patterns; alert when any region exceeds your SLO by >20%.
• Document your core model dependencies and review slug changes monthly, as OpenRouter adds, retires, and aliases models frequently.

Key takeaway: OpenRouter model slugs are the foundation of precise latency monitoring; by anchoring your probes to specific model identifiers and establishing per-model baselines across all 21 regions, you transform raw response-time data into actionable routing and cost optimization decisions that directly impact your application's responsiveness and operational efficiency.

Understanding OpenRouter model slugs

A model slug is OpenRouter's standardized way to name and reference a model. Instead of storing a long model ID or version string in your probe configuration, you reference the slug, a URL-friendly string like openai/gpt-4-turbo or meta-llama/llama-2-70b. Each slug maps to a specific model, version, and configuration on OpenRouter's infrastructure.

Why slugs matter for latency monitoring:

When you set up a probe with a slug, Observinio tells OpenRouter "test this exact model" and measures response time from your test region to OpenRouter's endpoint. If OpenRouter retires a model or aliases it to a newer version, the slug changes, and your probe configuration must update. By understanding slugs, you know exactly what model you're testing and can correlate latency trends with model-specific incidents (e.g., "Claude 3 Opus is slow from Singapore today").

Slugs also enable cost and performance trade-offs. You might probe gpt-4 for critical paths and cheaper models like gpt-3.5-turbo for less latency-sensitive flows, then compare TTFB across both to justify routing decisions to your team.

Fetching the complete model slug list

OpenRouter publishes its model catalog via a dedicated API endpoint and documentation file. Both are essential for keeping your probe configuration current.

Method 1: OpenRouter Models API endpoint

The canonical source is OpenRouter's /docs/llms.txt file and the models index:

"Documentation IndexFetch the complete documentation index at: /docs/llms.txtUse this file to discover all available pages before exploring further."

>, Get a model by its slug

To fetch a single model's metadata by slug:

curl -s "https://openrouter.ai/api/v1/models" \
  -H "Authorization: Bearer YOUR_OPENROUTER_API_KEY" | jq '.data[] | select(.id == "openai/gpt-4")'

This returns the model's current configuration, pricing, context window, and availability status. If a slug no longer exists, the API returns an empty result.

Method 2: Browse OpenRouter's model directory

Visit openrouter.ai/models to see the live catalog with slugs, provider labels, and pricing. Filter by provider (OpenAI, Anthropic, Meta, etc.) to narrow your choices. Note the slug in the URL or model card and use it in your Observinio probe.

Method 3: Query Observinio's probe history

If you've already created probes in Observinio, export your probe log to see which slugs you've monitored. This helps you identify the critical models in your stack and plan new probes for coverage gaps.

Building your core probe set

Not all models warrant continuous monitoring. Start with a focused baseline and expand based on usage and SLO requirements.

Recommended core probes

Tier 1: Mission-critical models (probe all 21 regions)

• openai/gpt-4-turbo, your primary chat model
• anthropic/claude-3-opus, alternative high-accuracy model
• meta-llama/llama-2-70b, self-hosted or budget fallback

Tier 2: Cost-sensitive models (probe 8–10 strategic regions)

• openai/gpt-3.5-turbo, lightweight fallback
• mistral/mixtral-8x7b, open-weight alternative

Tier 3: Experimental models (probe 3 regions: US-East, EU-West, APAC)

• New or recently released models you're evaluating

Practical: Core probe checklist

Setting latency baselines per model and region

Each model-region pair has its own latency fingerprint. OpenRouter's infrastructure, model serving framework, and network hops to your test location all affect response time. Over time, Observinio learns the expected TTFB and TTFT for each combination.

Why baselines matter

A model baseline tells you "under normal conditions, gpt-4-turbo completes its first token in 350 ms from Sydney." When Sydney's TTFB jumps to 600 ms, Observinio flags it as an anomaly. Without per-model baselines, you can't distinguish between:

• A regional outage at OpenRouter's Sydney facility
• Degradation specific to that model's serving tier
• Network routing issues between your test region and the provider

How Observinio establishes baselines

Run probes for 7–14 days without alerts enabled. Observinio collects samples and computes the 50th, 75th, and 95th percentile TTFB and TTFT for each model-region pair. Once a baseline is stable, enable email alerts with a threshold (e.g., "alert if p95 TTFB exceeds 1000 ms").

Practical: Baseline review step-by-step

1. Deploy your core probes (Tier 1 models, all 21 regions), this takes ~10 minutes in Observinio's UI
2. Wait 7 days without alerts to let data accumulate
3. Export the weekly latency report (Observinio sends this via email each Friday)
4. For each model-region pair, note the p50 and p95 TTFB, these are your baselines
5. Set alerts at p95 + 25%, e.g., if p95 is 400 ms, alert at 500 ms
6. Review alerts weekly to identify systemic vs. one-off delays

Handling model slug changes and deprecations

OpenRouter evolves its catalog frequently: models are aliased to newer versions, pricing tiers shift, or providers discontinue endpoints. Your probes must adapt.

Common slug changes

Scenario	Example	Action
Model aliased to newer version	openai/gpt-4 → openai/gpt-4-turbo	Update probe slug; monitor latency diff for 1 week
Model deprecated	anthropic/claude-2.1 retired	Remove probe or switch to claude-3-sonnet
New model released	openai/gpt-4o added	Add probe to Tier 3; evaluate latency vs. cost
Slug renamed	meta-llama/llama-2-7b → meta-llama/llama-2-7b-chat	Update config; no latency reset needed

Monitoring for slug deprecations

Subscribe to OpenRouter's API changelog (check their status page or docs site). Once a month, run this curl to verify your probes' slugs still exist:

for slug in "openai/gpt-4-turbo" "anthropic/claude-3-opus" "meta-llama/llama-2-70b"; do
  status=$(curl -s "https://openrouter.ai/api/v1/models/$slug" \
    -H "Authorization: Bearer YOUR_OPENROUTER_API_KEY" | jq -r '.data.id // "NOT_FOUND"')
  [ "$status" = "NOT_FOUND" ] && echo "WARNING: $slug no longer available"
done

If a slug is retired, Observinio will show errors in your probe logs. Delete the probe and create a new one with the successor slug.

Advanced: Routing decisions based on per-model latency

Once you have latency data for multiple models across regions, you can optimize routing. For example:

• EU traffic: Route to anthropic/claude-3-opus if TTFB is <300 ms; fall back to gpt-3.5-turbo if >400 ms
• APAC traffic: Prefer meta-llama/llama-2-70b (Open Router's APAC optimization); only use gpt-4 for critical requests
• Cost optimization: During peak hours, downgrade low-priority requests from gpt-4-turbo to gpt-3.5-turbo if latency remains <500 ms

Observinio's weekly latency report and daily degradation alerts give you the data to justify these routing rules to your team and update them as provider performance shifts.

FAQ

Keep your probes sharp with Observinio

OpenRouter's model catalog is rich and constantly evolving, and your monitoring must keep pace. By anchoring your probes to specific model slugs and regularly reviewing baselines, you transform raw latency data into actionable routing and cost decisions.

Observinio's daily probes across 21 regions and weekly email summaries give you the visibility to catch regional degradations before they hit production. Start with a focused Tier 1 probe set, establish baselines over one week, then scale probes to secondary models. Set degradation alerts, review monthly for slug changes, and let the data guide your provider and model-routing decisions.

Ready to get started? Set up your first OpenRouter probes and track model-specific latency across your critical regions.

Additional Resources

• Compare AI Models: Pricing, Context & Benchmarks - Compare 500+ LLMs from OpenAI, Anthropic, Google, Meta and more — pricing, context length, and benchmarks side by side, all through one API.
• Get a model by its slug - Returns full details for a single model identified by its author and slug (e.g. openai/gpt-4). Supports variant suffixes (e.g. openai/gpt-4:free) and ...
• OpenRouter Models - Unified Access to 400+ AI Models - The Models API returns a standardized JSON response format that provides comprehensive metadata for each available model. This schema is cached at the edge and ...