model_list:
  - model_name: qwen3.8-27b-local
    litellm_params:
      # Static name — llama.cpp serves whatever model it loaded regardless of
      # what's requested here; this string isn't shell-expanded (this file
      # isn't docker-compose.yml, .env vars don't reach it).
      model: openai/qwen3.8-27b-local
      api_base: http://llama-server:8080/v1
      api_key: local
      # Qwen3 is a reasoning model — it spends output tokens on
      # reasoning_content before ever writing content. Callers that don't
      # set their own max_tokens (Open WebUI's default request didn't) hit
      # llama.cpp's low default, so the model runs out mid-thought and
      # content comes back empty. This is a floor, not a cap — any caller
      # that passes its own max_tokens still overrides it.
      # Raised from 4096: confirmed in the wild (llama-server logs) that
      # 4096 wasn't enough — reasoning_content alone ate the whole budget on
      # a real request (n_gen = 4096 exactly, no answer ever written). At
      # ~26.7 t/s and a 65536-token context window, 16384 is a ~10-minute
      # worst case, not the full ~20-minute worst case 32768 would be.
      max_tokens: 16384
    model_info:
      # Shadow cloud-cost estimate — priced against Claude Sonnet 5's published
      # rate, not real spend (this proxy only ever routes to the local model).
      # Source: https://platform.claude.com/docs/en/about-claude/pricing,
      # checked 2026-08-25. Update these two numbers if that page changes.
      input_cost_per_token: 0.000002   # $2 / MTok
      output_cost_per_token: 0.00001   # $10 / MTok

  - model_name: local-embedding
    litellm_params:
      # Served by the dedicated embedding-server (nomic-embed-text-v1.5), not
      # the chat model — see docker-compose.yml. Called by litellm-pgvector
      # to embed knowledgebase content, and available directly at
      # /v1/embeddings for anything else that wants it.
      model: openai/local-embedding
      api_base: http://embedding-server:8080/v1
      api_key: local
    model_info:
      mode: embedding

# SearXNG-backed web search — a standalone REST endpoint (/v1/search/searxng-search),
# NOT a model-callable tool and not auto-injected into chat completions. See
# docs/research/litellm-searxng-search.md. Requires the litellm container to
# resolve search.home — see the `extra_hosts` entry in docker-compose.yml.
search_tools:
  - search_tool_name: searxng-search
    litellm_params:
      search_provider: searxng
      api_base: http://search.home/

# Knowledgebase / RAG, backed by the litellm-pgvector companion service (NOT
# Qdrant — LiteLLM's native vector-store feature has no Qdrant provider, see
# docs/research/litellm-knowledgebase.md). vector_store_id is this proxy's
# own identifier for the store, not assigned by a backend.
# Smoke-tested end-to-end against a running deploy (issue #24): search via
# both /v1/vector_stores/{id}/search directly and the file_search tool on a
# chat completion. Needed several fixes beyond this block to work — a
# missing api_key here, litellm-pgvector's Prisma schema never having been
# pushed, a 1536- vs 768-dim mismatch, and its create endpoint ignoring any
# caller-supplied id — see scripts/update.sh, scripts/ingest-memory.sh, and
# vendor/litellm-pgvector/'s local patches (models.py, main.py,
# prisma/schema.prisma).
vector_store_registry:
  - vector_store_name: memory-and-notes
    litellm_params:
      vector_store_id: "memory-and-notes"
      custom_llm_provider: pg_vector
      api_base: http://litellm-pgvector:8000
      # Required by litellm's pg_vector provider (see
      # PGVectorStoreConfig.validate_environment in litellm's source) — it's
      # the Bearer token litellm-pgvector's own API checks against its
      # SERVER_API_KEY. Was missing entirely, which is why every vector
      # store call was failing with "Incorrect API key provided: None"
      # before litellm-pgvector was ever reached. See issue #24.
      api_key: os.environ/LITELLM_PGVECTOR_API_KEY
      embedding_model: local-embedding

router_settings:
  # ponytail: LiteLLM's request-prioritization scheduler is beta (see
  # docs/proxy-request-priority.md) — exact settings key/shape must be
  # confirmed against LiteLLM's current docs and smoke-tested against
  # llama.cpp before workloads depend on it. Redis is available (see the
  # litellm service's REDIS_* env vars in docker-compose.yml) if the
  # scheduler needs shared state for it.
  enable_priority_scheduling: true

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY