Skip to main content

​
OpenRouter

OpenRouter is a first-class Kheish route driver. Use it when you want one daemon-owned route that can target vendor-prefixed model identifiers such as:
  • openai/gpt-5.4-mini
  • anthropic/claude-sonnet-4
  • google/gemini-2.5-pro
version = 1
default_route = "openrouter"

[routes.openrouter]
driver = "openrouter"
default_model = "openai/gpt-5.4-mini"
model_support = "any"
auth_ref = "openrouter.primary"
model_support = "any" is the normal OpenRouter setting because the model strings are usually vendor-prefixed. Bootstrap the secret slot before startup: 
export KHEISH_AUTH_STORE_MASTER_KEY="$(./target/debug/kheish-daemon secrets generate)"

./target/debug/kheish-daemon secrets set openrouter.primary \
  --offline \
  --state-root .kheish-daemon-data \
  --provider openrouter \
  --from-env OPENROUTER_API_KEY
Then start the daemon: 
./target/debug/kheish-daemon serve \
  --bind 127.0.0.1:4000 \
  --state-root .kheish-daemon-data \
  --workspace-root .kheish-workspace \
  --routes-file ./routes.toml
OpenRouter routes are API-key-backed routes. They do not use OpenAI account auth imports such as Codex.

​
Route-aware selectors

Use the configured route id as the selector prefix:
  • openrouter/openai/gpt-5.4-mini
  • openrouter/anthropic/claude-sonnet-4
Examples: 
./target/debug/kheish-daemon runtime set-model openrouter/openai/gpt-5.4-mini

./target/debug/kheish-daemon sessions input demo \
  --provider openrouter \
  --model openai/gpt-5.4-mini \
  "Summarize the attached files and be concise."
On a named-route daemon, provider means the route id. The backend request still receives the normalized model string without the openrouter/ prefix.

​
Current built-in surface

OpenRouter currently participates in these daemon-owned surfaces:
  • text runs
  • vision-capable runs with supported image attachments
  • generate_image
  • edit_image
  • generate_audio
  • daemon-owned speech-to-text and canonical-text derivation for supported audio assets
Current coarse route defaults for OpenRouter are:
  • multimodal_input = true
  • native_web_search = false
  • image_generation = true
  • image_edit = true
Those are the flags surfaced by runtime get today. Audio generation and transcription are real OpenRouter-backed daemon features, but they are surfaced through tool availability and configured transcription backends rather than a dedicated runtime capability flag.

​
Audio and asset behavior

OpenRouter-backed audio generation is exposed through generate_audio. The tool returns daemon-owned audio assets and may also return a transcript. To make generated audio visibly part of the final answer, the agent must follow generate_audio with emit_output and either:
  • include the returned asset ids in parts
  • or set include_artifacts_inline = true
The general asset store accepts broader retained audio formats such as:
  • audio/wav
  • audio/webm
  • audio/mpeg
  • audio/mp4
  • audio/m4a
Observation-source uploads remain stricter. microphone_segment sources still accept only audio/wav and audio/webm.

​
Operational notes

  • base_url is optional. The built-in provider defaults already target the normal OpenRouter API.
  • web_search does not currently use an OpenRouter-native provider backend.
  • runtime get does not currently expose an audio_generation route flag.
  • generate_audio appears only when the daemon has an audio backend configured for one route. Today, the built-in audio-generation backend is OpenRouter.
Read Providers and routing for route precedence and selector grammar, Tools for control-tool behavior, and Assets and multimodal input for asset normalization and transcription behavior.