In Google ADK, what do adk web, adk run, and adk api_server each give you?

## The three local entry points Google ADK ships a CLI whose job is to put a *loop* around your agent code before any of it reaches a cloud. The three commands that matter day to day are `adk web`, `adk run` and `adk api_server`. They differ only in the surface they wrap around the same agent, not in how the agent executes. ## What counts as "an agent" to the CLI All three discover agents by directory convention. An agent is a Python package folder containing `__init__.py` (which imports the agent module) and `agent.py` that defines a module-level `root_agent`. `adk web` and `adk api_server` are pointed at the **parent** directory holding one or more such folders, and each folder becomes a selectable app; `adk run` is pointed at the **agent folder itself**. A `.env` file inside the agent folder supplies model credentials and project settings. Getting this layout wrong is the single most common first-hour failure: the UI starts but the app dropdown is empty. ## adk web — the dev UI `adk web` serves a local web app on a localhost port. Beyond the chat box you get: - **Events** — the ordered list of events for the session, so you can open the exact function call the model emitted, the arguments it passed, and the function response that came back. This is where you catch a malformed tool argument that the chat transcript hides behind a fluent answer. - **Trace** — a span timeline for the turn: which LLM call took how long, which tool call sat inside it, and where the wall-clock went. - **State** — the current session state dictionary, so you can see what a tool actually wrote. - **Eval** — create an eval set, save the session you just ran into it as a case, and run cases back against the agent. The UI is a development tool, not a product surface. It talks to the same server routes `adk api_server` exposes. ## adk run — the terminal loop `adk run` starts an interactive text loop against one agent. It is the right choice on a remote box, inside a devcontainer, or when you want to script a quick smoke check without a browser. It prints the agent's responses; the rich per-event inspection lives in the web UI. ## adk api_server — the HTTP surface `adk api_server` starts a FastAPI application locally. The important routes are `POST /run` (run a turn, get the events back as a list) and `POST /run_sse` (the same turn streamed as server-sent events, which is what you want for token-by-token UX). Session lifecycle is handled by REST endpoints under `/apps/{app_name}/users/{user_id}/sessions/{session_id}` — create a session, fetch it, list events. Because this is the same app that a Cloud Run deployment serves, integrating your frontend against `adk api_server` locally means the contract does not change when you deploy. ## Session persistence is opt-in By default every one of these uses in-memory session storage: sessions live in the process and die with it. For a dev loop where you want conversations to survive restarts, point the command at a database URI via its session-service URI option (in google-adk 2.x the flag is `--session_service_uri`; earlier 0.x/1.x releases spelled it `--session_db_url`). There are matching options for the artifact and memory services. Knowing this default is what saves you from the "my agent has amnesia" bug report. ## Choosing between them Use `adk web` while you are shaping prompts, tools and instructions — the Events and Trace tabs are the whole reason ADK bundles a UI. Use `adk run` for headless smoke checks and CI-adjacent scripting. Use `adk api_server` the moment another process needs to call the agent, because it is the deployable shape. None of the three is a load-bearing production server on its own: production means either the same FastAPI app inside your own container on Cloud Run, or a managed Vertex AI Agent Engine deployment.