agentic-api vs plano
Rust gateway that gives vLLM a stateful, OpenAI-compatible Responses API: server-side conversation state, server-side tool loops, SSE and WebSocket streaming, background runs — Codex-ready. — versus — AI-native Envoy-based proxy for agentic apps: agent orchestration via a 4B routing model, smart LLM routing, guardrail filter chains and zero-code OTEL traces. Rust, framework-agnostic.
Both move agentic logic out of the client and into a proxy. Plano is an Envoy-based proxy with routing and orchestration across models; agentic-api is a Responses-API server bound to vLLM. Cross-model proxy vs stateful API for one engine.
| agentic-api | plano | |
|---|---|---|
| Stars | 167 | 7.0k |
| Forks | 46 | 487 |
| Language | Rust | Rust |
| License | Apache-2.0 | Apache-2.0 |
| Last activity | today | 17 days ago |
| Topics | gateway, local | gateway, orchestration |
| Curated connections | 5 | 7 |
agentic-api — the curator's take
Install it when your client code has become the agent loop: instead of replaying transcripts and executing tools yourself, one POST /v1/responses with previous_response_id and the server hydrates state, runs the tool chain (explicit gateway/client/provider ownership), streams, and continues. Point Codex at it and drive Codex with open models on your own GPUs — no OpenAI account. Validated against the Open Responses suite with replay cassettes. NOT a multi-provider router — vLLM is the backend today — and the Anthropic-style Messages API and higher-level Interactions API are still planned; 167 stars, early.
plano — the curator's take
Reach for it when multi-agent code is drowning in hidden middleware — intent routing, provider quirks, guardrail hooks, tracing glue. Plano moves all of that out-of-process: agents are plain OpenAI-compatible HTTP servers in any language, orchestration is YAML plus a purpose-built 4B router model. NOT for a quick single-agent demo (it adds an infra hop and Envoy operational surface), and note the catch: the hosted Plano-Orchestrator LLM is free-tier only — production means running the routing models yourself or getting API keys. If you only need provider unification, LiteLLM is lighter.