Connect Google ADK agents to Router One through the LiteLlm connector

Install google-adk and litellm, then set your credentials

Use Python 3.10 or newer. Install google-adk and litellm: the LiteLlm connector page states that ADK requires litellm>=1.84, and the connector is listed as supported in ADK Python only, so this guide does not apply to the TypeScript, Go, Java, or Kotlin ADKs. adk create my_agent scaffolds the folder that adk run expects: agent.py with a root_agent definition, __init__.py, and a .env file. The quickstart keeps the API key in that .env file and then runs both commands; adk run loads it unless ADK_DISABLE_LOAD_DOTENV is set, and variables already exported in the shell keep precedence over the file, so the macOS/Linux shell example below and a .env file are both valid places for the two values. Replace both placeholders with a Router One key and the exact ID of a current model that supports Chat Completions. The ROUTER_ONE_* names belong to this example, which reads them explicitly; OPENAI_API_KEY is not needed, because the key is passed to LiteLlm directly.

python -m pip install google-adk
python -m pip install "litellm>=1.84"
export ROUTER_ONE_API_KEY="sk-your-router-one-key"
export ROUTER_ONE_MODEL_ID="<exact-model-id-from-/models>"

Configure Google ADK to use the Router One base URL

Save this as my_agent/agent.py, keep the __init__.py that adk create generated next to it, and run adk run my_agent from the parent folder. LiteLlm is ADK's wrapper around the litellm library: every keyword argument besides model is stored and passed through to litellm's completion call, which is how api_base and api_key reach it. model must start with openai/: the LiteLLM docs define that prefix as the instruction to call an OpenAI /chat/completions endpoint, and LiteLLM splits the string at the first slash only, so everything after openai/ is sent unchanged as the request's model field. The example builds it from ROUTER_ONE_MODEL_ID, and a GPT-family ID such as openai/gpt-5.5 therefore becomes openai/openai/gpt-5.5. api_base is the /v1 base URL with nothing appended; LiteLLM uses the OpenAI Python client underneath, which adds /chat/completions itself. api_key is the Router One key; passing it here means neither OPENAI_API_KEY nor OPENAI_API_BASE needs to exist. root_agent is the only required element of an ADK agent folder, and name, instruction, and the model object are the LlmAgent fields the LiteLLM connector page uses. adk web --port 8000 from the same parent folder opens the development UI at http://localhost:8000:

import os

from google.adk.agents import LlmAgent
from google.adk.models.lite_llm import LiteLlm

# openai/ makes LiteLLM call an OpenAI /chat/completions endpoint; the rest of
# the string is sent unchanged as the model field (openai/openai/gpt-5.5 for a GPT ID).
model = LiteLlm(
    model="openai/" + os.environ["ROUTER_ONE_MODEL_ID"],
    api_base="https://api.router.one/v1",  # ends in /v1, nothing after it
    api_key=os.environ["ROUTER_ONE_API_KEY"],
)

# root_agent is the only required element of the agent folder.
root_agent = LlmAgent(
    name="router_one_agent",
    model=model,
    instruction="Answer in one short sentence.",
)

# From the parent folder:  adk run my_agent     (or: adk web --port 8000)

Which value goes where, and how to verify it

Everything Router One needs is inside the LiteLlm object; the rest of the agent is unchanged. The rows give each field, the value to enter, and the check that proves it, followed by the two paths this guide does not configure:

Budget one agent and reconcile its model calls

One user turn can produce several model requests: the connector makes one LiteLLM call per LLM call in the run, and each function-tool result goes back to the model as a further Chat Completions request. RunConfig.max_llm_calls bounds the number of LLM calls in one run — 500 unless you pass a value or set ADK_MAX_LLM_CALLS, and a value of 0 or less removes the bound; it counts calls, not money. Retries are separate requests too: when a request carries http_options.retry_options, ADK forwards its attempts value as LiteLLM's num_retries, and every attempt that reaches the gateway is its own request with its own request_id, trace, and charge. Give each agent a dedicated Router One key with maxSpend; a run that reaches the cap gets HTTP 402 on its next call while the wallet and other keys are untouched. The Event history in adk web shows the events of a run, and adk run --save_session writes them to a JSON file; neither shows a bill. The charge per call is the trace in Dashboard → Logs — model, input and output tokens, cost, latency, status, and request_id — so reconcile by key, time, exact model, and request_id, and keep the request_id when reporting a failure. Router One serves the model requests and records their traces; sessions, state, tool execution, and the agent loop stay in your process.

Which model ID should Google ADK send?

Copy the exact model ID from /models, preserving case, hyphens, and version suffixes; do not substitute a display name. Open its detail page and match the supported API endpoints, context window, and capabilities such as tool calling to the provider and features selected in Google ADK. A catalog listing does not mean the client can use every feature of that model. Give each tool a dedicated API key with a maxSpend cap.

Which API protocol is Google ADK using?

OpenAI-compatible describes an interface format; it does not make Chat Completions (/v1/chat/completions), Responses (/v1/responses), and Anthropic Messages (/v1/messages) interchangeable. Check the installed client version, provider configuration, and actual request path against the model detail page and API compatibility fact sheet. A successful plain-text chat does not establish support for hosted tools, conversation state, or file-editing features.

Verify the Google ADK call in your request trace

Send a simple text request from Google ADK, then match its trace in Dashboard → Logs by time, model, and request_id: tokens, cost, latency, and status. Next, test streaming, tool calls, and multi-turn history separately. For failures, retain the actual request path, full error message, and request_id. If there is no matching log, check client configuration and connectivity before attributing the error to the gateway or upstream.

FAQ