open-router_skill

Overview

This skill configures OpenRouter model routing with provider authentication, model selection, fallback chains, and cost-aware defaults to support stable multi-model workflows. It keeps routing policies, provider choices, incidents, and budgets in a local memory directory for repeatable operations. The skill is designed to make routing decisions explicit, verifiable, and resilient to provider-specific failures. It minimizes cost drift by enforcing task-class budgets and cost-aware defaults.

How this skill works

On first use you are directed to a setup document to define activation boundaries, reliability targets, and routing preferences before changing configuration. The skill stores routing profiles and constraints under ~/open-router/, including providers, routing rules, incidents, and budget guardrails. It validates provider auth with a minimal request, discovers model metadata from OpenRouter, and routes inference requests to selected models while applying fallbacks and cost rules. Changes are applied one layer at a time and recorded for repeatability.

When to use it

• Connecting an OpenAI-compatible workflow to OpenRouter while keeping provider auth explicit.
• Selecting models by task class (coding, summarization, extraction, long-context synthesis, analysis).
• Creating resilient fallback chains that span provider families to avoid cascading failures.
• Enforcing cost ceilings and routing low-stakes tasks to cheaper models.
• Verifying routing and budget changes with quick verification prompts before rollout.

Best practices

• Classify workloads first and map each class to a primary model plus at least one fallback from a different provider family.
• Store routing state and rationale under ~/open-router/ and save verification outcomes for repeatability.
• Validate OPENROUTER_API_KEY via a minimal test request; never paste keys into logs or chat memory.
• Design fallbacks for specific failure modes (rate limit, outage, latency, quality) rather than convenience.
• Change only one layer at a time (model selection, fallback policy, or budget) and rerun verification prompts after each change.

Example use cases

• Route high-impact analysis tasks to premium models while directing batch extraction jobs to cost-optimized models with strict token budgets.
• Configure multi-provider fallback chains so a coding completion falls back to a different provider if rate limits occur.
• Maintain an incident log and switch routing rules automatically when an outage is recorded, preserving low-cost fallback behavior.
• Run a verification prompt suite after each routing update and store outcomes in memory for audit and rollback.
• Tune cost guardrails by task class to prevent spend drift during a broad rollout of a new model.