One request, eight plugins.

• Cheap checks first. Authentication and rate limiting take a millisecond or two, so unknown callers and runaway scripts are turned away before anything expensive runs.
• Clean the prompt before you look it up. Redaction runs before the cache, so personal data never becomes part of a cache key, and the prompt guard runs before the cache so a blocked prompt can never be answered from it.
• Route only what will really be sent. The router runs after the cache, so a cache hit never pays for a model decision it does not need.
• Log everything, including rejections. The logging plugin runs for every request. Blocked requests are often the most useful records: they show attacks, broken clients and limits that are set too tight.

• Identity that flows through the chain. Rate limits, budgets, routing rules and cost reports all depend on knowing which consumer sent the request.
• Detection you have tested. Pattern matching catches obvious email addresses and card numbers. Names in free text, unusual formats and indirect prompt injection need stronger detection and regular testing against your own traffic.
• Fallbacks that are actually compatible. A secondary provider needs the same request format, enough context window and capacity, and has to meet any rules about where data is processed.
• Limits on retries as well as requests. Fallback hides a provider's 429 from users, but without a rate limit in front of it a runaway client simply moves on to the next provider's quota.
• Configuration as code. In products such as Kong, each step here is a plugin configured per route or per consumer, so the chain can be reviewed, versioned and tested like any other code.

It runs entirely in your browser with a fixed set of example requests. It does not call a gateway or any AI provider. Latencies, token counts and prices are illustrative values chosen to make each decision visible; they are not benchmarks or published prices.