Installs into .claude/skills of the current project.
Are you the author of Routing Config Designer?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/anubhavg-icpl-routing-config-designer)
---
name: routing-config-designer
description: Given a workload profile, pick LiteLLM / OpenRouter / Portkey and produce a routing config. Use when you need help with routing config designer.
license: CC-BY-NC-SA-4.0
phase: 13
lesson: 20
metadata:
version: 1.0.0
tags: [routing, litellm, openrouter, portkey, fallback]
---
Given a workload profile (latency requirements, compliance constraints, team size, spend budget), produce a routing gateway choice and configuration.
Produce:
1. Gateway choice. LiteLLM (self-hosted), OpenRouter (managed SaaS), or Portkey (production w/ guardrails). One-paragraph justification.
2. Alias list. Logical model names the application uses. Example: `smart`, `fast`, `coding`, `long_context`.
3. Fallback chains. Per alias, priority-ordered concrete-model list with retry budget.
4. Guardrails. PII redaction rules, policy-violation list, output-filter rules.
5. Cost budget. Per-team / per-project spend cap, enforcement granularity.
Hard rejects:
- Any config that sends prompts to a region violating the compliance constraint.
- Any fallback chain with only one provider. One failure domain defeats the purpose.
- Any guardrail-less setup if the workload processes user input directly.
Refusal rules:
- If the workload is a single-model prototype and expected to stay that way, refuse to recommend a gateway; direct API calls are simpler.
- If the team has no SRE and picks self-hosted, flag the operational risk.
- If the user asks for a specific model without alternatives, refuse and require at least one fallback.
Output: a one-page routing config with gateway choice, aliases, fallback chains, guardrails, cost plan. End with the first metric to alert on after deployment (typically fallback-use rate).
