Three gateway jobs sit between clients and vLLM inference
Agentic API owns state hydration, server-side tool execution, and protocol transport while vLLM keeps responsibility for tokenization and generation. A client can send previous_response_id instead of replaying an entire conversation. The gateway rebuilds model-visible history, calls the upstream, executes tools assigned to it, continues the loop, and persists one public response. HTTP, server-sent events, and WebSockets use the same orchestration core, which reduces the chance that each transport develops different tool behavior.
That division is useful for organizations already operating vLLM. Codex can point its Responses provider at the gateway, and Claude Code can use the Messages endpoint against an open model. SQLite is the default store for a local session, while the CLI recommends PostgreSQL when sessions are shared. Unknown or ambiguous tool shapes are returned rather than executed by default. Configured MCP entries can limit tool names, hosts, and approval behavior, giving operators one place to define the execution boundary.
What happened when we ran it
Our sandbox installed commit 905dbab in 485 seconds, adding 36 packages and consuming 72 MB. The Python build completed successfully in 6 seconds. The checkout contained 447 files, roughly 70,114 lines of source, and occupied 8.2 MB before installation. Pip-audit reported 0 known vulnerabilities in the installed Python environment. Those figures describe the packaging path in a 3-CPU, 8 GB container, not a running vLLM model server.
Pytest finished with exit code 1 after 11 seconds. Its summary reported 109 passed, 2 failed, 3 skipped, and 1 collection or setup error out of 112. Both failed cases exercised scripts/check-python-wheel.sh. One log line says cargo: command not found; the other says the checker could not launch cargo metadata. The separate error names scripts/test_claude_code_replay_server.py, but the provided tail contains no cause, so no further diagnosis is justified.
The result exposes a mixed-toolchain assumption. The Python wheel embeds Rust gateway binaries and validates their versions against Cargo workspace metadata. A Python 3.12 image with uv was enough to install 36 packages and build in 6 seconds, yet it was incomplete for those wheel checks. The repository itself includes 8 CI workflow files, a Dockerfile, and a tests directory. Contributors should install the Rust toolchain before treating the Python test command as self-contained.
Version 0.5.0 wheels come from workflows, not PyPI
The README calls v0.5.0 a build-only Python release. Its wheel artifacts are obtained from a release workflow and installed from an absolute local path; the GitHub release page itself lists no downloadable assets. Public-index commands such as uv pip install agentic-api are explicitly reserved for a future publication gate. This makes the Python launcher harder to consume and pin than its familiar package name suggests.
The base wheel is for a remote vLLM server and does not install vLLM. The optional local extra supplies a pinned vLLM runtime only on supported Linux hosts, where model serving also needs appropriate GPU resources. Rust users can build the agentic and agentic-server binaries directly. A doctor command checks the packaged binary and local or remote mode, but operators still need to validate the upstream URL, model identifier, database, credentials, and readiness behavior.
One retention bug blocks zero-data-retention WebSockets
Open issue 238 reports that a WebSocket request with store: false still persisted state that a fresh connection could retrieve through previous_response_id. The report includes a negative control without the ID and identifies server-side persistence as the observed difference. For any deployment promising zero data retention, that is a release blocker on the affected path. Use cannot be justified by the issue merely being open; the fix needs a regression test and verification in the deployed commit.
Persistence deserves attention even outside that bug. WebSocket sessions force streaming and stored state according to the architecture document. SQLite is simple for one process, while shared sessions call for PostgreSQL and an explicit retention policy. The roadmap puts production storage backends, retention, compaction, and request-lifecycle observability in longer-term work. Until those pieces land, operators must decide how long conversation and tool data lives, how it is deleted, and who can query it.
Tool execution adds credentials and network authority
Built-in web search requires You.com configuration, and remote MCP servers can introduce headers, environment values, and separate trust domains. The config file stores the environment-variable name for the web-search key rather than the key itself. Documentation recommends environment injection or a secret manager for sensitive values and a restrictive file mode if database credentials or MCP settings enter the file. OIDC can protect HTTP and WebSocket routes in a shared deployment.
The ownership model is the project's best design choice. Client tools such as Codex shell and editor actions stay client-executed. Gateway tools can run web search, file search, or MCP calls and continue the model loop. Provider tools pass upstream. A --yolo launcher option disables Claude permission checks and Codex approvals or sandboxing, and the README limits it to an externally isolated environment. That warning should be read literally because the gateway already has network and database authority.
Five releases and 68 open items show fast, unfinished work
GitHub recorded the last push on September 7, 2026. The project had 46 open issues, 22 open pull requests, and 211 stars. Five releases arrived between July 13 and August 25, ending at v0.5.0. Current work covers WebSocket multiplexing, response limits, image inputs, error propagation, and Messages cassettes. This is active development around protocol behavior, not maintenance of a settled gateway.
The docs are substantial, with architecture, design decisions, Kubernetes manifests, authentication guides, and a Docker build. One status mismatch remains visible: the API table labels Messages as planned, while later sections document a working /v1/messages path and v0.5.0 says it preserves Claude Code transport fidelity. Agentic API is the focused choice when stateful Codex or Claude Code traffic must sit directly above vLLM. For provider routing choose LiteLLM; for application-owned workflows choose LangGraph; for plain inference stay with vLLM.