Utrzymywanie sesji

• Sticky load balancing – model wirtualny z load balancingiem kieruje każdy request sesji do targetu, który obsłużył ją jako pierwszy. Dzięki temu prompt cache providera pozostaje rozgrzany, a zachowanie modelu spójne w trakcie rozmowy.
• Sticky wybór klucza API – gdy jeden provider ma kilka kluczy, każdy request w wykrytej sesji używa tego samego klucza, co zachowuje powiązanie z prompt cache providera.
• Wątki w logach audytowych – strona Audit Logs w dashboardzie grupuje requesty sesji w jeden wątek: najnowszy request jest wierszem, a rozwijany element pokazuje pod nim starsze requesty.
• Użycie i koszt per sesja – rekordy użycia niosą to samo ID sesji w danym zakresie, więc dashboard i Admin API mogą raportować requesty, tokeny i wydatki u providera dla jednej rozmowy lub zadania agenta.

​

Jak identyfikowana jest sesja

1. Nagłówki sesji – wbudowany rejestr obejmuje nagłówki wysyłane przez znane narzędzia oraz konwencje gatewayów:

   Nagłówek	Wysyłany przez
   X-Session-Id	OpenCode, Kilo Code, klienty ogólne
   X-Opencode-Session	OpenCode, pi i inne klienty używające dialektu OpenCode Zen
   X-Claude-Code-Session-Id	Claude Code (udokumentowany dla gatewayów)
   Session-Id / Session_id	Codex CLI (obecny / starszy), Roo Code
   X-Litellm-Session-Id	konwencja LiteLLM
   Helicone-Session-Id	konwencja Helicone
   Agent-Session-Id	Goose

2. Pola body – dla klientów, które oznaczają sesje w body requestu: Anthropic metadata.user_id (Claude Code umieszcza tam UUID swojej sesji; parsowane są zarówno obecny, jak i starszy format), session_id (konwencja OpenRouter), litellm_session_id, prompt_cache_key (Zed i inne klienty OpenAI, które używają jednego klucza cache na rozmowę) oraz referencje conversation w /v1/responses.
3. Automatyczne wykrywanie – requesty chat i responses bez jawnego sygnału są grupowane według początku rozmowy: modelu, kontekstu systemowego, narzędzi i wiadomości aż do pierwszej tury użytkownika. Kolejne requesty wysyłają ten prefiks ponownie bez zmian, więc agent, który po prostu odtwarza swoją historię (Aider, Cline, Continue, …), nadal dostaje stabilne ID sesji (auto-…) bez żadnych zmian po stronie klienta.

​

Sticky load balancing

virtual_models:
  - source: "smart"
    strategy: round_robin
    session_affinity: false   # domyślnie: true
    targets:
      - model: "openai/gpt-4o"
      - model: "anthropic/claude-sonnet-5"

​

Wątki w logach audytowych

​

Użycie i koszt per sesja

curl -H "Authorization: Bearer $GOMODEL_MASTER_KEY" \
  "http://localhost:8080/admin/usage/sessions?days=7&limit=50&offset=0"

{
  "entries": [
    {
      "session_id": "scoped-0123456789abcdef0123456789abcdef",
      "user_path": "/team/alpha",
      "requests": 8,
      "input_tokens": 24000,
      "output_tokens": 4100,
      "total_tokens": 28100,
      "input_cost": 0.42,
      "output_cost": 0.16,
      "total_cost": 0.58
    }
  ],
  "total": 1,
  "limit": 50,
  "offset": 0
}

​

Konfiguracja

# Główny przełącznik identyfikacji sesji
SESSION_KEEPING_ENABLED=true
# Wykrywanie na podstawie treści dla requestów bez jawnego sygnału
SESSION_AUTO_DETECT=true
# Wbudowany rejestr nagłówków/pól body
SESSION_BUILTIN_RULES=true
# Dodatkowe nagłówki sesji (numerowane od 1), łączone z wbudowanymi.
# Opcjonalna transformacja "session-uuid" wyciąga wartość session_<uuid>.
SESSION_HEADER_1=X-My-Session
SESSION_HEADER_1_TRANSFORM=

session:
  enabled: true
  auto_detect: true
  builtin_rules: true
  headers:
    - header: X-My-Session