https://docs.all-hands.dev/ logo
Join Slack
Powered by
Hello! I've been tinkering around with OpenHands f...
# openhands-cloud
s
Hello! I've been tinkering around with OpenHands for a couple days. Today I spent a long time trying to make a self-hosted setup using Fly.io sprites for ephemeral isolated machines. That turns out to be harder than it sounds, so I decided to give OpenHands Cloud a try. It started off great with the default DeepSeek model, but when I added OpenAI / Anthropic / OpenRouter keys, suddenly I started getting authentication errors on the first message in any given conversation. I am no longer able to get responses from any model, including the default DeepSeek one hosted by OpenHands. Here's what I get just now with the 
litellm_proxy/deepseek-v4-flash
model:
Copy code
Error code: 401 - {'error': {'message': 'Authentication Error, Invalid proxy server token passed. Received API Key = sk-asfasdf..., Key Hash (Token) =asdasdf... Unable to find token in cache or `LiteLLM_VerificationTokenTable`', 'type': 'token_not_found_in_db', 'param': 'key', 'code': '401'}}
I tried logging out and in again, but beyond that I don't see any mechanism at all to remedy it.
đź‘€ 1
l
Hey @strong-vase-18073, if you’re using a key from another provider, could you click “Basic” on the authentication, select the correct provider, and enter the model?
s
That helped for getting the default deepseek model to work again. Anthropic and OpenRouter models are not working. I did add my default 
ANTHROPIC_WORKSPACE_ID
in secrets. Unfortunately once a model errors the session is basically unrecoverable so trying out different things means waiting for a box to spin up each time.
Oh! I got openrouter to work. One of the models I had configured via the advanced tab wasn't actually available so that may have been the issue
l
Great!
d
I'm also experiencing similar issue tried , groq, mistral, openai model none was working.
b
i'm also experiencing the same dead org-default system managed llm key, Error code: 401 - {'error': {'message': 'Authentication Error, Invalid proxy server token passed. Received API Key = sk-...8aSP, Key Hash (Token) =569909a917a742e1c954a5ae2ff043fb10fff299956707ca9f9ce64c1f257585. Unable to find token in cache or `LiteLLM_VerificationTokenTable`', 'type': 'token_not_found_in_db', 'param': 'key', 'code': '401'}} Help?
c
cc @elegant-branch-54423
For the record, my agent (an OpenHands, running from local machine) fixed it via API
You could maybe give your agent (not running in the Cloud) the issue I linked?
b
i'll rather talk to a human thanks
e
hi @blue-grass-57262 I will message you
b
hey @elegant-branch-54423 check your dms
c
I looked a bit around with my agent, and I have a few suggestions. 1. Refresh the 
openhands/
key As noted in the ticket above, the 
openhands/
key is never refreshed by the code; emptying it and refreshing it via API (or via database) makes it work again. I'd suggest doing that for the affected accounts; they have an 
openhands/
key that should be easy to just rotate, thus it will work again for people. 2. Hypothesis: PRs enterprise#168 and enterprise#178 from August 2026 are making interesting assumptions, and appear related to the breaking of 
openhands/
provider. I think, and please note that this is an hypothesis, that we have 2 different expected behaviors of the term “managed litellm key” in 2 different scenarios:
(a) for orgs, with managed keys, the expected behavior is something like: • users don’t have their own keys • org key is saved in org settings / refreshed there • user profiles shouldn’t save keys • when the user uses a key, the code picks it up from the deprecated 
user_info.agent_settings.llm_settings
- please do note, on an aside, that it’s legacy and deprecated • this kind of code avoids to refresh “BYOR” (b) individual users, personal workspace/org: • may use 
openhands/
provider • in that case, 
openhands
app litellm proxy behaves like a managed proxy, with a managed key • it seems saved in “org settings” too • but for these users, the `openhands/`` key is not refreshed
It looks to me like some PRs are assuming that the only “managed litellm api keys” are in case (a)
thus I see behavior in the code, that I don’t fully understand to be fair, that does something like “go through all this user’s LLM profiles, and replace their key with only the org settings key” • that could happen in case (a), but it shouldn’t in case (b) Conversely, there’s code avoiding to refresh an “org settings” key, if the user is not in an org. But… in case (b), 
openhands
provider has a managed llm key, and use of it from individual Cloud users should still get a refreshed key, otherwise it would stop working
3. A little suggestion • a Cloud LLM live test suite, with real LLMs, “real” org, realistic users • a few LLM profiles, one on 
openhands/
, one on an org managed key, random other direct LLM API e.g. a DeepSeek direct • represent both users from an org and individual • direct conversation, automation, switch profile, set active profile; perms • represent all the possibilities, they’re not that many, but the code is tricky, it seems to me For the record, there is another bug with it, though I’m not sure if this is my particular edge case, when 
openhands/
LLM in Automations got its key overridden unexpectedly. I personally found that live LLM tests are great, idk, I have an implementation of all 4 LLM APIs and I don’t know how I could ever account for the endless provider quirks without live testing. Not unit tests, not CI, live setups to serve for regression testing. 🤷
e
Thanks Engel! Just as an update to folks, we have a small team of engineers working through these errors. Turns out it's been quite complex, but I think we're close. Copying @ancient-car-4311 from our engineering team for visibility
Open in Slack
PreviousNext
Powered by