weaviate
Openrouter API cannot work with company network
I met a issue when I try to use openrouter api. My network is LAN of my company but I export a proxy. And before I try openrouter api, I can successfully call model like qwen3-32b based on ollama. But it seems that open source llm model cannot call function good. So I turn to openrouter for calling gemini model because of your recommendation,
Could you help me identify the problem？ Thanks a lot!
Hey there, thanks for your interest in the project!
Could you try running a brief example in python using the same configuration, based on the openrouter docs on LiteLLM?
If this works, then there's something strange happening with Elysia, otherwise it is a network based issue with LiteLLM/openrouter that unfortunately we cannot do much about
hi Danny, Actually it works with python based on the openrouter docs on LiteLLM in the same configuration (company LAN with proxy)
And just to confirm that your setup is exactly the same in that python file and within the Elysia configuration?
Could you perhaps try using the Elysia python package and testing if that works? E.g., just running
from elysia import Tree
tree = Tree()
response, objects = tree("hi")
provided that you have your API keys and models set up in the environment or via something like:
from elysia import configure
configure(
base_model="gpt-4.1-mini",
base_provider="openai",
complex_model="gpt-4.1",
complex_provider="openai",
openai_api_key="..." # replace with your API key
)
I follow your instruction strictly sorry, the error log is bit long I get the same error as I tried in Elysia server I think there may be still a problem with the company LAN network even I export proxy I may ask our IT and system architect colleagues about that later
(Elysia) alvchat@achaiserveir02:~$ python elysia_lan.py /home/alvchat/.conda/envs/Elysia/lib/python3.11/site-packages/spacy/util.py:930: UserWarning: [W094] Model 'en_core_web_sm' (2.2.0) specifies an under-constrained spaCy version requirement: >=2.2.0. This can lead to compatibility problems with older versions, or as new spaCy versions are released, because the model may say it's compatible when it's not. Consider changing the "spacy_version" in your meta.json to a version range, with a lower and upper pin. For example: >=3.8.7,<3.9.0 warnings.warn(warn_msg) Warning: Using blank English model with tokenizer instead of en_core_web_sm [09/17/25 16:38:14] WARNING WCD_URL is not set. All Weaviate functionality will be disabled. client.py:201 ╭─ User prompt ─╮ │ │ │ hi │ │ │ ╰───────────────╯ /home/alvchat/.conda/envs/Elysia/lib/python3.11/site-packages/httpx/_models.py:408: DeprecationWarning: Use 'content=<...>' to upload raw bytes/text content. headers, stream = encode_request( Traceback (most recent call last): File "/home/alvchat/.conda/envs/Elysia/lib/python3.11/site-packages/elysia/util/async_util.py", line 24, in asyncio_run loop = asyncio.get_running_loop() ^^^^^^^^^^^^^^^^^^^^^^^^^^ RuntimeError: no running event loop
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/alvchat/elysia_lan.py", line 14, in
Very strange, sorry you are experiencing that issue. Since it seems to be a network error rather than an Elysia one, I don't think there's much I can do about it unfortunately!
I'll leave this open in case anyone else runs into the same problem. If so, then I will look into it further.
No problem, I will try this project with my personal laptop some time later. If there is update about this error I will report to you (mainly come from our system architect)
@dannyjameswilliams hi Danny, I discuss with my system architect and find a solution, I think it may be helpful if someone would use Elysia in the company LAN internet.
Elysia fails due to the following reasons: It relies on environment-based API key discovery (e.g., OPENROUTER_API_KEY), which may be missing or invisible at the time of the call. It uses LiteLLM’s aiohttp transport, potentially with HTTP/2 and streaming—features that are often incompatible with corporate proxies and can lead to "Server disconnected" errors.
Key causes of "Server disconnected": The API key is missing or not visible in the Elysia execution path (e.g., environment variable not exported or cleared by an internal context manager). The combination of aiohttp, HTTP/2, and streaming over a corporate proxy is unreliable; proxies frequently terminate the connection before the response is fully read.
Recommended fixes: Ensure authentication is always available: Export OPENROUTER_API_KEY and mirror it to OPENAI_API_KEY for compatibility with providers that use that variable. Make proxy and SSL settings visible to the Elysia process: Export proxy environment variables: HTTP_PROXY, HTTPS_PROXY, and NO_PROXY.
If necessary, disable SSL verification or specify custom certificate bundles using: PYTHONHTTPSVERIFY=0 SSL_VERIFY=false REQUESTS_CA_BUNDLE="" CURL_CA_BUNDLE=""
Use a simpler, proxy-compatible transport: Disable aiohttp and HTTP/2: LITELLM_USE_AIOHTTP=0 HTTPX_HTTP2=false
Increase robustness with: HTTPX_TIMEOUT=120 LITELLM_NUM_RETRIES=5
Hey @jianwen095 sorry for the late reply - would you be able to try #60 to see if this fixes your issue?
@dannyjameswilliams hi Danny, I discuss with my system architect and find a solution, I think it may be helpful if someone would use Elysia in the company LAN internet.
Elysia fails due to the following reasons: It relies on environment-based API key discovery (e.g., OPENROUTER_API_KEY), which may be missing or invisible at the time of the call. It uses LiteLLM’s aiohttp transport, potentially with HTTP/2 and streaming—features that are often incompatible with corporate proxies and can lead to "Server disconnected" errors.
Key causes of "Server disconnected": The API key is missing or not visible in the Elysia execution path (e.g., environment variable not exported or cleared by an internal context manager). The combination of aiohttp, HTTP/2, and streaming over a corporate proxy is unreliable; proxies frequently terminate the connection before the response is fully read.
Recommended fixes: Ensure authentication is always available: Export OPENROUTER_API_KEY and mirror it to OPENAI_API_KEY for compatibility with providers that use that variable. Make proxy and SSL settings visible to the Elysia process: Export proxy environment variables: HTTP_PROXY, HTTPS_PROXY, and NO_PROXY.
If necessary, disable SSL verification or specify custom certificate bundles using: PYTHONHTTPSVERIFY=0 SSL_VERIFY=false REQUESTS_CA_BUNDLE="" CURL_CA_BUNDLE=""
Use a simpler, proxy-compatible transport: Disable aiohttp and HTTP/2: LITELLM_USE_AIOHTTP=0 HTTPX_HTTP2=false
Increase robustness with: HTTPX_TIMEOUT=120 LITELLM_NUM_RETRIES=5
Very helpful! This solution fixed an issue that had been bothering me for a whole day. I encountered it when using Elysia with my company's internal OpenAI-compatible endpoint. The key is to set $env:SSL_VERIFY="false" on the company network
