Setup
On first use, read setup.md to align activation boundaries, reliability goals, and routing preferences before making configuration changes.
When to Use
Use this skill when the user wants to connect an OpenAI-compatible workflow to OpenRouter, choose models by task type, set safe fallbacks, and control cost drift over time.
Architecture
Memory lives in ~/open-router/. See memory-template.md for structure.
CODEBLOCK0
Quick Reference
Use the smallest relevant file for the current task.
| Topic | File |
|---|
| Setup and activation preferences | INLINECODE3 |
| Memory template |
memory-template.md |
| Authentication and provider wiring |
auth-and-provider.md |
| Routing patterns by workload |
routing-playbooks.md |
| Reliability and fallback handling |
fallback-reliability.md |
| Cost controls and spend reviews |
cost-guardrails.md |
Core Rules
1. Start from Workload Classes, Not Model Hype
- - Classify requests first: coding, analysis, extraction, summarization, or long-context synthesis.
- Map each class to a primary model and a fallback before changing any defaults.
2. Keep Authentication Explicit and Verifiable
- - Use
OPENROUTER_API_KEY from the local environment, never pasted into logs or chat memory. - Validate auth with a minimal request before applying routing changes.
3. Design Fallbacks for Failure Modes, Not Convenience
- - Separate fallback reasons: rate limit, provider outage, latency spike, or output quality failure.
- Keep at least one fallback from a different provider family for resilience.
4. Enforce Cost Boundaries Before Throughput Tuning
- - Set cost ceilings by task class and check expected token burn before broad rollout.
- Route low-stakes tasks to cheaper models and reserve premium models for high-impact tasks.
5. Change One Layer at a Time
- - Modify either model selection, fallback policy, or budget limits in a single iteration.
- After each change, run a quick verification prompt set and record outcome.
6. Record Decisions for Repeatability
- - Save the final routing policy, rationale, and known tradeoffs in memory.
- Reuse proven policies instead of repeatedly rebuilding from scratch.
Common Traps
- - Choosing one model for every task -> higher cost and unstable quality under varied workloads.
- Using same-family fallback chain only -> cascading failures during provider-specific incidents.
- Ignoring token limits for long inputs -> truncated responses and hidden quality loss.
- Changing routing and budgets simultaneously -> unclear root cause when quality drops.
- Running without verification prompts -> broken routing detected only after user-facing failures.
External Endpoints
These endpoints are used only to discover model metadata and execute routed inference requests under explicit user task intent.
| Endpoint | Data Sent | Purpose |
|---|
| https://openrouter.ai/api/v1/models | none or auth header only | Discover current model catalog and metadata |
| https://openrouter.ai/api/v1/chat/completions |
user prompt content and selected model id | Execute routed inference requests |
No other data is sent externally.
Security & Privacy
Data that leaves your machine:
- - Prompt text and selected model metadata sent to OpenRouter when inference is requested.
Data that stays local:
- - Routing notes and preferences under
~/open-router/. - Local environment variable references and verification logs.
This skill does NOT:
- - Request raw API keys in chat.
- Store plaintext secrets in skill memory files.
- Modify files outside
~/open-router/ for its own state.
Trust
By using this skill, prompt content is sent to OpenRouter for model execution.
Only install if you trust this service with your data.
Related Skills
Install with
clawhub install <slug> if user confirms:
- -
api — API request design, payload shaping, and response validation patterns - INLINECODE14 — credential handling and auth troubleshooting workflows
- INLINECODE15 — model comparison and selection guidance
- INLINECODE16 — runtime health checks and incident tracking practices
Feedback
- - If useful: INLINECODE17
- Stay updated: INLINECODE18
设置
首次使用时,请先阅读 setup.md,在做出配置更改前对齐激活边界、可靠性目标和路由偏好。
使用时机
当用户希望将兼容 OpenAI 的工作流连接到 OpenRouter、按任务类型选择模型、设置安全回退方案并控制长期成本漂移时,使用此技能。
架构
记忆文件位于 ~/open-router/。结构请参见 memory-template.md。
~/open-router/
├── memory.md # 活跃路由配置文件和约束条件
├── providers.md # 已确认的提供商和认证选择
├── routing-rules.md # 任务 -> 模型及回退策略
├── incidents.md # 故障、速率限制和恢复记录
└── budgets.md # 支出防护措施和优化操作
快速参考
针对当前任务使用最小的相关文件。
memory-template.md |
| 认证和提供商配置 | auth-and-provider.md |
| 按工作负载的路由模式 | routing-playbooks.md |
| 可靠性和回退处理 | fallback-reliability.md |
| 成本控制和支出审查 | cost-guardrails.md |
核心规则
1. 从工作负载类别出发,而非追逐模型热度
- - 首先对请求进行分类:编码、分析、提取、摘要或长上下文综合。
- 在更改任何默认设置之前,将每个类别映射到一个主模型和一个回退模型。
2. 保持认证显式且可验证
- - 使用本地环境中的 OPENROUTERAPIKEY,切勿粘贴到日志或聊天记忆中。
- 在应用路由更改之前,通过最小请求验证认证。
3. 为故障模式设计回退,而非为了便利
- - 区分回退原因:速率限制、提供商故障、延迟飙升或输出质量失败。
- 至少保留一个来自不同提供商家族的回退方案以确保弹性。
4. 在优化吞吐量之前先设定成本边界
- - 按任务类别设置成本上限,并在大规模推广前检查预期的令牌消耗。
- 将低风险任务路由到更便宜的模型,将优质模型保留给高影响任务。
5. 一次只更改一层
- - 在单次迭代中,仅修改模型选择、回退策略或预算限制中的一项。
- 每次更改后,运行一组快速验证提示并记录结果。
6. 记录决策以确保可重复性
- - 将最终的路由策略、理由和已知权衡保存在记忆中。
- 重用经过验证的策略,而不是反复从头构建。
常见陷阱
- - 为每个任务选择同一个模型 -> 成本更高,且在不同工作负载下质量不稳定。
- 仅使用同家族回退链 -> 在特定提供商故障期间导致级联失败。
- 忽略长输入的令牌限制 -> 响应被截断,质量损失隐蔽。
- 同时更改路由和预算 -> 质量下降时难以确定根本原因。
- 未使用验证提示运行 -> 直到用户面对失败才发现路由损坏。
外部端点
这些端点仅用于发现模型元数据,并在明确的用户任务意图下执行路由推理请求。
| 端点 | 发送的数据 | 目的 |
|---|
| https://openrouter.ai/api/v1/models | 无或仅认证头 | 发现当前模型目录和元数据 |
| https://openrouter.ai/api/v1/chat/completions |
用户提示内容和所选模型 ID | 执行路由推理请求 |
不会向外部发送其他数据。
安全与隐私
离开您机器的数据:
- - 请求推理时发送给 OpenRouter 的提示文本和所选模型元数据。
保留在本地的数据:
- - ~/open-router/ 下的路由记录和偏好。
- 本地环境变量引用和验证日志。
此技能不会:
- - 在聊天中请求原始 API 密钥。
- 在技能记忆文件中存储明文密钥。
- 为自身状态修改 ~/open-router/ 之外的文件。
信任
使用此技能即表示提示内容将被发送到 OpenRouter 进行模型执行。
仅当您信任此服务处理您的数据时才安装。
相关技能
如果用户确认,使用 clawhub install 安装:
- - api — API 请求设计、负载构建和响应验证模式
- auth — 凭据处理和认证故障排除工作流
- models — 模型比较和选择指导
- monitoring — 运行时健康检查和事件跟踪实践
反馈
- - 如果觉得有用:clawhub star open-router
- 保持更新:clawhub sync