The ai-proxy Translation Table: Five Kong Plugins, Five Different Homes
The most useful page in any gateway evaluation is the translation table: not what each product has, but where each job you currently run goes. For teams on Kong, the jobs live in the plugin chain hanging off ai-proxy. Here is where they land if the LLM slice moves behind Kong to a managed gateway — including the rows with no landing spot, because those rows decide the evaluation. (The full comparison this draws from is the Kong vs nRouter for LLM traffic analysis.)
The five mappings
ai-proxy (routing + provider auth) → nothing to configure. The plugin itself — service, route, auth block, model mapping per provider — disappears. Callers keep the same wire format and point at a different base URL with a different key. There is no per-provider config to maintain because there are no provider credentials on your side at all: custody moves with the endpoint.
ai-prompt-guard (deny patterns) → guardrail rules scoped per key, team, or org. The job survives; the mechanism changes. Instead of regex patterns declared in gateway config — each covering one attack shape at a time — the rules attach to the caller identity. One honest caveat: a pattern list and a guardrail policy are different instruments, and neither covers the whole prompt-attack surface by itself.
ai-rate-limiting-advanced + your Redis → RPM/TPM limits per key, no Redis. The shared-counter problem the Redis strategy solves — consistent limits across data-plane nodes — is the gateway operator's problem on the managed side. Your dependency list loses a stateful system from the request path.
ai-prompt-template → server-side templates with versions and rollback. Same job, different address: templates live with the gateway rather than in plugin config, and versioning is a property of the template store instead of your config repo.
Consumers + ACLs (who may call what) → virtual keys. A consumer change plus a redeploy becomes a key minted, scoped, or revoked in one action. This is the mapping that changes incident response the most: revocation stops being a config event.
The three rows with no home
A translation table that maps everything is a sales document. Three Kong plugins have no nRouter equivalent: ai-semantic-cache, ai-rag-injector, and ai-llm-as-judge. If semantic caching is already saving you real money on a high-repetition workload, there is nothing to translate to — stay. (nRouter does ship ordinary response caching for identical requests and prompt compression for qualified models; neither is a semantic cache, and the comparison says so.)
Two more rows are not plugin rows at all. Kong's control plane covers REST, gRPC, and GraphQL — the managed gateway fronts LLM calls only. And Kong runs in your topology, including hard data residency; a hosted endpoint cannot answer that requirement. Either one ends the evaluation honestly.
Why the table is short
Notice what the mappings have in common: every job that lands, lands on the caller's identity — a key — rather than on gateway configuration. That is the architectural difference underneath the feature lists. Kong composes capabilities into a config you own and operate; a purpose-built gateway binds them to keys it operates. Neither is universally better. But when you are pricing the switch, price the translation, not the logos: five jobs move, three do not exist on the other side, and two requirements — topology and protocol breadth — outrank the whole table. The full side-by-side is the Kong vs nRouter for LLM traffic comparison.
Kong, Kong Gateway, and Kong Konnect are trademarks of Kong Inc. nRouter is not affiliated with or endorsed by Kong Inc.