litellm-proxy-gateway

LiteLLM Proxy Gateway

Workflow

1. Determine whether a single application can just use the SDK; adopt the Proxy only for centralized permissions, governance, or a shared entry point.
2. Check the LiteLLM version and config schema.
3. Create a minimal model_list, with stable model_name mapped to provider-prefixed models.
4. Inject provider keys, master key, database URL, and Redis secret from environment variables.
5. Start the Proxy and verify aliases and error paths with the OpenAI SDK.
6. Load as needed litellm-routing-reliability、litellm-cost-governance、litellm-observability、litellm-guardrails-safety or litellm-mcp-skills-gateway。
7. Deliver development, testing, and production environment differences and verification evidence.

When config, client smoke test, or version notes are needed, read Experiments and References。

Security Baseline

• Do not put real secrets in configuration, code, command history, or teaching materials.
• Production clients do not use the master key.
• Do not treat provider keys and Proxy virtual keys as the same permission tier.
• Use TLS, a controlled network, and minimal public endpoints for external services; local HTTP examples must not be carried over directly to production environments.

Acceptance

• Config can be loaded and contains no real secrets.
• An OpenAI-compatible client can complete a smoke request through an alias.
• Unauthorized keys are rejected.
• Specialized governance needs have been routed to the corresponding skill, rather than being oversimplified within this skill.