vh
163a7252ec
The gpt-5-mini calls were Lobe's System Agent -- a background model, separate from the chat model, used for auto-naming conversations, history summarization, translation, query rewrite, thread naming, and assistant metadata. Its default is openai/gpt-5-mini, which our OpenAI provider (the gateway) forwards verbatim; the scoped key blocks it, so every background task 403'd and the log filled with 'Tried to access gpt-5-mini' while auto-naming silently failed. Set SYSTEM_AGENT to route all six documented keys (topic, translation, agentMeta, queryRewrite, historyCompress, thread) at fleet models -- summarizer for the naming/summarize tasks (same seat as gen at temp 0), gen where quality matters. Any key left unset falls back to the gpt-5-mini default, so all six are explicit. Notably this one IS env-configurable (SYSTEM_AGENT), unlike the per-model output-token cap which is UI-only -- a mixed result on the manageable-by-agent axis.
13 lines
713 B
Bash
13 lines
713 B
Bash
# lobe-chat on esh-docker-vm. Real .env lives on the host and is NEVER committed.
|
|
# Populate from the vault:
|
|
# secret get esh-docker-vm/lobe-chat-litellm-key -> OPENAI_API_KEY
|
|
# secret get esh-docker-vm/lobe-chat-access-code -> ACCESS_CODE
|
|
# secret get esh-docker-vm/lobe-chat-key-vaults-secret -> KEY_VAULTS_SECRET
|
|
LOBE_PORT=3210
|
|
OPENAI_PROXY_URL=http://10.250.50.70:4000/v1
|
|
OPENAI_API_KEY=
|
|
ACCESS_CODE=
|
|
KEY_VAULTS_SECRET=
|
|
# System-agent background model routing (avoids the gpt-5-mini default 403ing on the scoped key)
|
|
SYSTEM_AGENT=topic=openai/summarizer,translation=openai/gen,agentMeta=openai/gen,queryRewrite=openai/summarizer,historyCompress=openai/summarizer,thread=openai/summarizer
|