Cloud API providers (Gemini, Bedrock, Azure)

This page covers the three hyperscaler model back-ends that need more than a single API key to set up: Google Gemini (direct API, Gemini CLI OAuth, and Vertex AI), AWS Bedrock (SigV4 or Bearer auth, cross-region inference profiles), and Azure OpenAI (resource/deployment-scoped endpoints). It also explains the [model_providers] named-profile layout that lets you point Revka at a custom or Codex-style endpoint without hand-editing default_provider and api_url separately.

Reach for this page when your models live behind GCP, AWS, or Azure rather than a vendor’s first-party API. For the simpler “set a key and chat” providers, start with the Provider quickstart; for the full table of every back-end, see the Provider catalog.

Note

All three providers resolve credentials with the same priority Revka uses everywhere: an explicit config value → the provider-specific environment variable → the generic REVKA_API_KEY / API_KEY fallback. The provider-specific env vars below are the recommended way to configure cloud credentials.

Google Gemini

The gemini provider is a full-featured Google integration with several authentication strategies. Select it with default_provider = "gemini" or the -p gemini CLI flag.

default_provider = "gemini"
default_model    = "gemini-2.5-pro"

revka agent -p gemini --model gemini-2.5-pro -m "Hello"

Thinking-model reasoning parts are filtered out of the final response, so you get clean text back from Gemini’s reasoning models.

Authentication strategies

The provider resolves credentials in this order, stopping at the first one that succeeds:

1. Vertex AI ADC (active when GOOGLE_GENAI_USE_VERTEXAI is true/1 and GOOGLE_CLOUD_PROJECT is set) — checked before the explicit API key.
2. Explicit API key in config.toml (api_key).
3. GEMINI_API_KEY environment variable.
4. GOOGLE_API_KEY environment variable.
5. Managed OAuth profile stored by revka auth login --provider gemini.
6. Gemini CLI OAuth tokens auto-discovered from ~/.gemini/oauth_creds.json.

Field	Where	Meaning
GEMINI_API_KEY	env var	Direct API key, sent as the ?key= query parameter.
GOOGLE_API_KEY	env var	Alternate name for the direct API key.
GOOGLE_CLOUD_PROJECT	env var	GCP project ID used for OAuth/Vertex requests (falls back to GOOGLE_CLOUD_PROJECT_ID).
GOOGLE_APPLICATION_CREDENTIALS	env var	Path to a service-account JSON for Application Default Credentials (ADC).

Two API endpoints

Gemini talks to two different endpoints depending on how you authenticate:

• API-key users hit the public endpoint https://generativelanguage.googleapis.com/v1beta with the key passed as ?key=….
• OAuth users (Gemini CLI or managed profiles) hit Google’s internal Code Assist endpoint https://cloudcode-pa.googleapis.com/v1internal, with the token sent as Authorization: Bearer ….

OAuth tokens are refreshed in-process, so a long-running gateway keeps working without manual re-authentication.

Vertex AI and ADC

To run Gemini through Vertex AI instead of the public API, configure the Vertex environment and keep default_provider = "gemini":

export GOOGLE_GENAI_USE_VERTEXAI=1
export GOOGLE_CLOUD_PROJECT="my-gcp-project"
export GOOGLE_CLOUD_LOCATION="us-central1"   # default region

Vertex AI requires Google credentials reachable on the host:

• On Cloud Run, GCE, or GKE, the GCP metadata server supplies credentials automatically (keyless) when the service account has Vertex access.
• Off-GCP, set GOOGLE_APPLICATION_CREDENTIALS to a service-account JSON so ADC can resolve a credential. Vertex AI is not reachable from a non-GCP host without it.

Tip

If you only want to reuse an existing Gemini CLI subscription without exposing an API key, the subprocess-based gemini-cli provider runs the gemini binary directly. See OAuth & subscription providers.

AWS Bedrock

The bedrock provider uses the AWS Bedrock Converse API. It supports native tool calling and prompt caching (cachePoint), and signs requests itself — there is no AWS SDK dependency. Select it with default_provider = "bedrock" or -p bedrock.

default_provider = "bedrock"
default_model    = "anthropic.claude-sonnet-4-5-20250929-v1:0"

Each request is an HTTPS POST to the regional Bedrock Runtime endpoint:

POST https://bedrock-runtime.{region}.amazonaws.com/model/{model_id}/converse

The default region is us-east-1. Default output is capped at 4096 tokens; override with provider_max_tokens in config.

Caution

Bedrock model IDs differ from the public Anthropic API IDs — use Bedrock’s anthropic.claude-* format (for example anthropic.claude-sonnet-4-5-20250929-v1:0), not the bare Anthropic ID.

SigV4 vs Bearer

Bedrock supports two authentication modes, and a Bearer token always takes precedence when present:

Mode	Trigger	Credentials
Bearer token	BEDROCK_API_KEY is set	The token is sent as Authorization: Bearer …. Simplest option; preferred when set.
SigV4 signing	No BEDROCK_API_KEY	Standard AWS Access Key / Secret Key signing against the bedrock signing service.

For SigV4, credentials are resolved from the environment first, then from EC2 instance metadata:

Variable	Meaning
AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY	Long-lived access keys for SigV4.
AWS_SESSION_TOKEN	Temporary/STS session token (when using assumed-role credentials).
AWS_REGION or AWS_DEFAULT_REGION	Signing/endpoint region. Default: us-east-1.
BEDROCK_API_KEY	Optional Bearer token; overrides SigV4 when set.

On EC2, ECS, or Lambda with an attached IAM role, Revka discovers temporary credentials automatically via EC2 IMDSv2 (the instance metadata service) — no keys need to be set in the environment.

Cross-region inference profiles

Bedrock cross-region inference profiles (which spread load across regions for higher throughput) are supported. To use one, include the region-group prefix in the model ID — for example, prefix us. for the US inference profile:

default_provider = "bedrock"
default_model    = "us.anthropic.claude-sonnet-4-5-20250929-v1:0"

The prefix is part of the model ID, not a separate setting; if you omit it you address the regional model directly instead of the inference profile.

Azure OpenAI

The azure-openai provider calls the Azure OpenAI Service Chat Completions endpoint, scoped to a resource and deployment rather than a model name. It supports native tool calling and reasoning-content handling. Select it with default_provider = "azure-openai" or -p azure. Accepted aliases: azure, azure-openai, azure_openai.

default_provider = "azure-openai"
default_model    = "gpt-4o"

The endpoint and credentials come from environment variables:

export AZURE_OPENAI_API_KEY="<your-key>"
export AZURE_OPENAI_RESOURCE="my-resource"
export AZURE_OPENAI_DEPLOYMENT="gpt-4o"
export AZURE_OPENAI_API_VERSION="2024-08-01-preview"   # optional

Variable	Default	Meaning
AZURE_OPENAI_API_KEY	—	API key, sent in the api-key request header (not a Bearer token).
AZURE_OPENAI_RESOURCE	my-resource	Azure resource name — the <resource> in the endpoint hostname.
AZURE_OPENAI_DEPLOYMENT	gpt-4o	Deployment name. This, not default_model, decides which model serves the request.
AZURE_OPENAI_API_VERSION	2024-08-01-preview	API version; bump it when Microsoft ships a new GA version.

Revka builds the request URL from those values:

POST https://{resource}.openai.azure.com/openai/deployments/{deployment}/chat/completions?api-version={version}
api-key: {AZURE_OPENAI_API_KEY}

Note

On Azure, the deployment name is the model selector — the request body carries no model field. The default_model in config.toml is informational; set AZURE_OPENAI_DEPLOYMENT to the deployment you actually want to hit.

[model_providers] named profiles

[model_providers] lets you define named provider profiles in config.toml — a Codex app-server-compatible layout — and then activate one just by naming it in default_provider. When the active provider matches a profile key, Revka applies that profile’s settings on top of your top-level config (top-level values you set explicitly always win).

default_provider = "my-endpoint"

[model_providers.my-endpoint]
base_url    = "https://your-api.example.com/v1"
api_path    = "/chat/completions"   # optional path override
max_tokens  = 8192                  # optional output cap
wire_api    = "chat_completions"    # or "responses"

Field	Type	Meaning
name	string	Provider type/name to switch to (e.g. openai, a custom profile id). Optional if base_url is set.
base_url	URL (http/https)	OpenAI-compatible base URL. Optional if name is set.
api_path	string	Custom request path suffix instead of the default /v1/chat/completions.
wire_api	string	Protocol variant: chat_completions or responses.
requires_openai_auth	bool	If true, load OpenAI auth material (OPENAI_API_KEY or ~/.codex/auth.json) when no key is set.
azure_openai_resource	string	Azure resource name for an Azure-style profile.
azure_openai_deployment	string	Azure deployment name.
azure_openai_api_version	string	Azure API version (defaults to 2024-08-01-preview).
max_tokens	integer	Maximum output tokens; useful when a platform default exceeds a model’s real limit.

Each profile must define at least one of name or base_url, and any base_url must be a valid http/https URL — otherwise config validation fails at load time. How activation resolves:

• wire_api = "responses" routes the request through the OpenAI Codex Responses API path.
• Otherwise, if name differs from the profile key, Revka switches default_provider to name.
• Otherwise, a base_url alone activates the profile as a custom:<base_url> endpoint.

This is the cleanest way to keep several endpoint definitions side by side and flip between them by changing a single default_provider line. For raw custom: / anthropic-custom: endpoints and extra_headers, see Local, self-hosted & custom endpoints.

Related pages

• Provider quickstart — pick a provider, set a key, run your first chat.
• Provider catalog — every back-end with base URLs, env vars, and capabilities.
• OAuth & subscription providers — Gemini CLI, Codex, Claude Code, and other token-based logins.
• Routing, reliability & tuning — fallbacks, hint: routing, timeouts, and provider_max_tokens.
• revka models, providers & auth — refresh model catalogs and manage OAuth profiles.
• Config: provider, agent & routing — the config.toml keys behind these providers.