You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for flagging this. I checked the current 1.3.1 source on main (5076683), and the main application client now accepts a configurable LLM timeout.
You can add this to the existing [llm] section in your everos.toml, then restart EverOS:
[llm]
timeout_seconds = 240
Or set EVEROS_LLM__TIMEOUT_SECONDS=240 in the environment of the process that starts EverOS. An exported environment value takes precedence over TOML. Putting it only in a .env file requires your launcher to load that file; Settings does not load it automatically.
I tested both configuration paths against the real client constructors: 180 seconds from the environment and 240 seconds from TOML reached the EverAlgo client, OpenAI SDK, and HTTPX timeouts. I also checked environment-over-TOML precedence, the 60-second default, and rejection of zero/negative values. No live model request was used, so this does not claim that the original endpoint error has been reproduced and eliminated.
Closing the configuration request as addressed. #341 stays open for the separate provider-factory path and the missing template/documentation updates. If requests still time out after setting this and restarting, please share the EverOS version, model/provider, and a redacted error so we can investigate that behavior separately.
Activity
cyfyifanchen commentedon Sep 9, 2026
Thanks for flagging this. I checked the current 1.3.1 source on
main(5076683), and the main application client now accepts a configurable LLM timeout.You can add this to the existing
[llm]section in youreveros.toml, then restart EverOS:Or set
EVEROS_LLM__TIMEOUT_SECONDS=240in the environment of the process that starts EverOS. An exported environment value takes precedence over TOML. Putting it only in a.envfile requires your launcher to load that file; Settings does not load it automatically.I tested both configuration paths against the real client constructors: 180 seconds from the environment and 240 seconds from TOML reached the EverAlgo client, OpenAI SDK, and HTTPX timeouts. I also checked environment-over-TOML precedence, the 60-second default, and rejection of zero/negative values. No live model request was used, so this does not claim that the original endpoint error has been reproduced and eliminated.
Closing the configuration request as addressed. #341 stays open for the separate provider-factory path and the missing template/documentation updates. If requests still time out after setting this and restarting, please share the EverOS version, model/provider, and a redacted error so we can investigate that behavior separately.