#Getting both vision and browser errors on Nous. Issues with API. I have credits.

1 messages · Page 1 of 1 (latest)

old knot
#

2026-04-18 22:11:45,477 ERROR tools.vision_tools: Error analyzing image: Error code: 404 - {'status': 404, 'message': "Couldn't find that, sorry."}

eager void
#

That log line does point to a real provider-side 404, but it does not look like a simple “out of credits” failure.

Important detail from current Hermes code: vision and browser do not use the same Nous path.

Vision goes through the auxiliary provider router. In auto mode it tries your main provider first, then OpenRouter, then Nous. Browser automation on Nous is separate: it uses the paid Nous Tool Gateway and Browser Use routing, and that depends on the browser tool actually being configured to use the gateway.

So “I have credits” by itself does not prove either path is enabled correctly.

The specific vision error you posted:
Error code: 404 - {'status': 404, 'message': "Couldn't find that, sorry."}
usually means Hermes reached an endpoint, but the model/route being hit is not valid for that request. That is more consistent with a routing or config mismatch than with ordinary balance exhaustion.

Please send these three things so we can separate the two failures cleanly:

  1. /debug
  2. hermes status
  3. Whether your browser tool is configured for:
    • Nous subscription / Tool Gateway
    • or a direct Browser Use / Browserbase key

If you can, also paste the relevant parts of hermes tools or your config.yaml for:

  • browser
  • auxiliary.vision
  • model.provider

Right now the strongest read is:
the vision 404 is a bad route/model/backend selection issue, and the browser issue may be a separate Tool Gateway configuration problem rather than a shared “Nous credits” problem.

If you provide logs, I'll check on it tomorrow if anyone else hasn't gotten to this thread to help by then.

old knot
#

Ok I can do that, but why was browser working before I setup my nous sub?

old knot
old knot
#

Also I have openrouter credits so if that’s my aux by auto would it still not work?

burnt parrot
#

can't view image

old knot
#

And now in telegram the bot is failing all together, once I switched to nous nothing is working

burnt parrot
old knot
burnt parrot
#

can't view image

old knot
#

And why would it be working in telegram then if they’re all using the same setup?

burnt parrot
old knot
#

But how does the exact setup working in telegram but not the terminal?

velvet shoal
#

Does the subscription have minimax m2.7 ?

eager void
#

That screenshot helps.

What it shows is:
you are currently on Provider: Nous Portal
your main model is xiaomi/mimo-v2-pro
you have OpenRouter set
and you also have a direct Browser Use key set.

That explains a lot.

Browser likely worked before your Nous subscription because it was using your direct Browser Use key. Browser and vision do not share the same path. After switching model/provider setup, Hermes can start using different routes for different tools.

Also, very important: if you switch model/provider setup, you need to restart the gateway for the messaging gateway to fully pick up those changes. Terminal and gateway do not always behave the same right after a switch, because the gateway can still be holding older session/runtime state until restart.

On the vision side, mimo-v2-pro is text-only. So if vision is resolving through the current Nous/main-provider path first, that can fail even if you also have OpenRouter credits. Having OpenRouter configured does not guarantee the first resolved vision route is valid.

So the likely picture is:
browser used to work on the direct Browser Use key,
then provider/model changes changed the routing,
the gateway may not have been restarted after the switch,
and now vision and browser are failing for different reasons.

Please send all of the logs/links you have for this, not just one piece. If there are 3 links, send all 3. Feel free to redact anything sensitive if you want, but I want the full set because partial logs make this way harder to diagnose.

Please include:

  • all /debug output or dump links
  • the relevant config.yaml sections for:
    • browser
    • auxiliary.vision
    • model

And after any provider/model change, restart the gateway before retesting so we are not mixing old gateway state with new config.

old knot
#

I dont have a browser key, never had a browser key or a vision key. I dont know how any of this happened. I have restarted the gateway multiple times and nothing works.

eager void
#

I’m not saying you manually set a browser key or a vision key.

What I’m saying is that Hermes is clearly resolving into a bad current setup state somewhere, and since you’ve already restarted the gateway multiple times, I would stop treating this as a stale-restart issue.

At this point, the next step is to make the vision path explicit instead of relying on auto. Please set a known vision-capable auxiliary model/provider in auxiliary.vision, make sure your browser config matches how you actually want to run browser tools, and then retest.

Right now I still do not have the current config/logs I asked for, so I’m stuck guessing between multiple possible routes.

Please send the current:

  • model
  • auxiliary.vision
  • browser

And your /debug output or links.

If you’re running in Docker, say that too, because that can absolutely affect what Hermes resolves at runtime.

old knot
#

I know but I dont want to paste any sensitive info here

#

right now I'm trying to build and I keep getting this error, idk if its the model or something else but it just keeps erroring out

curl -s -o /dev/null -w "%{http_code}" http://localhost:8899/trace-replay.html 8090.0s
┊ 💻 $ curl -s http://localhost:8899/trace-replay.html | head -20 0.1s [error]
┊ 💻 $ curl -s http://localhost:8899/ | head -10 0.1s [error]
┊ 💻 $ curl -s --max-time 5 http://localhost:8899/trace-replay.html | wc -c 0.1s [error]
┊ 💻 $ curl -s --max-time 5 http://127.0.0.1:8899/ 2>&1 | head -5 0.1s [error]
┊ 💻 $ lsof -ti :8899 2>/dev/null && echo "port in use" || echo "port free" 0.1s [error]
┊ 🐍 exec from hermes_tools import terminal 3.0s
┊ 💬 Sorry, got interrupted. Let me check the state and get back on track:
┊ 💻 $ lsof -ti :8899 2>/dev/null && echo "server running" || echo "no server" 0.1s [error]

#

browser:

image.png
#

I'm not running in docker

eager void
#

I can’t debug this any further from partial screenshots and mixed terminal snippets.

Right now this thread has multiple different problems tangled together:

  • browser routing
  • vision routing
  • local localhost:8899 app/build failures

I need actual logs before I can separate those cleanly. Redact anything sensitive if you want, that is completely fine, but I need the real log output rather than screenshots/snippets.

At minimum, please send:

  • the current vision error logs
  • the current browser error logs
  • the relevant agent.log / gateway.log output around each failure

I’m not going to keep guessing from here. Once the logs are in the thread, I can come back to it.

old knot
#

Ok there are about 2k lines, how sould you like me share them?

old knot
old knot
#

let me know what lese you need

eager void
#

Thanks, this is enough to separate the failures.

This is not one shared browser/vision/Nous issue.

On the browser side, your current config is forcing the managed Browser Use gateway path:

browser.cloud_provider: browser-use
browser.use_gateway: true

With that setting, Hermes prefers the managed Nous Browser Use gateway path over a direct Browser Use API key. So if you want Hermes to use the direct Browser Use credential it sees in your status screen, set browser.use_gateway: false. If you want the managed Nous path instead, keep it true, but then the exact same profile/process running Hermes needs a valid paid Nous auth state from hermes auth.

On the vision side, your current config is explicitly pinned to OpenRouter:

auxiliary.vision.provider: openrouter
auxiliary.vision.model: google/gemini-2.5-flash

So this is not currently using xiaomi/mimo-v2-pro for image analysis. Also, the blank auxiliary.vision.api_key field does not by itself disable the env fallback path. If OPENROUTER_API_KEY is loaded in that process, Hermes will still use it. That makes the 404 look more like a bad resolved model/route on the vision backend than a generic “Nous credits” problem.

Separately, your logs show two more real issues:

  • repeated Telegram HTTPX.ReadError / fallback IP failures
  • resolve_provider_client: nous requested but Nous Portal not configured (run: hermes auth)

That means at least one Hermes process is running without valid Nous auth, and your own shutdown diagnostics show multiple Hermes processes at once, so config/runtime state is likely getting mixed between processes.

At this point I would do one clean retest in a single profile/process:

  1. Stop all Hermes processes.
  2. Start one Hermes instance in the exact profile you want to test.
  3. Pick one browser path and stick to it for the retest:
    direct Browser Use: set browser.use_gateway: false
    managed Nous gateway: leave it true and re-run hermes auth
  4. Leave vision pinned to OpenRouter for now and retest that separately from browser.

If it still fails after that clean restart, reply in-thread with text, not screenshots, for:

  • hermes status
  • the model, browser, and auxiliary.vision sections of config.yaml
  • the first vision error after restart
  • the first browser error after restart

That will let us isolate the exact remaining branch cleanly and close this out.

old knot
#

Ok tested and I think we're good for now. I do get this error, but I assume its unrelated? Maybe just from API connection to Kimi from NOUS?

⚠️ No response from provider for 511s (model: moonshotai/kimi-k2.6, context: ~73,117 tokens). Reconnecting...
⚠️ No response from provider for 1037s (model: moonshotai/kimi-k2.6, context: ~73,117 tokens). Reconnecting...
⚠️ Connection to provider dropped (ReadTimeout). Reconnecting… (attempt 2/3)
🔄 Reconnected — resuming…