Omniroute 3.8.50 intermittently going offline

[jsmithteamiis]

I have noticed in the last 36 hours that omniroute has been going offline for no reason, I haven't been able to pinpoint anything in the logs. Does anyone have any ideas where to look first for log entries. I am on Windows 11 and there is nothing in the eventviewer.

Jonathon

[linuxtopia]

what was your installation method?
if you use npm/bun package can you try that;

omniroute serve --daemon --no-open

on the terminal

omniroute stop

will kill the process when you wanna stop it.

[gonisulaimann]

Here is where to find OmniRoute's logs on Windows 11 and the most common root causes for silent offline drops:

1. Where to find the log files on Windows 11

OmniRoute stores its persistent state and log files in your user home directory:

• Default log directory: %USERPROFILE%\.omniroute\logs\
• Main runtime logs: %USERPROFILE%\.omniroute\logs\gateway.log and daemon.log
• SQLite database & WAL journals: %USERPROFILE%\.omniroute\data.db and data.db-wal

If you started it via the CLI with --daemon, check ~/.omniroute/logs/daemon.log.

2. Common Windows 11 root causes for intermittent offline drops

1. Windows Modern Standby (Connected Standby / Sleep):
   By default on Windows 11, when the display turns off or the machine enters Modern Standby, Windows aggressively puts non-service background Node.js processes into low-power suspension and disconnects TCP listeners. To verify, check if the offline drop correlates with inactivity.

2. SQLite WAL File Locks (OneDrive / Indexer interference):
   If your user profile directory is synchronized by Microsoft OneDrive, or if Windows Search Indexer is scanning .omniroute, it can lock data.db-wal during SQLite checkpointing (PRAGMA wal_checkpoint(TRUNCATE)), causing the Node process to exit with an unhandled SQLITE_BUSY error. Exclude %USERPROFILE%\.omniroute from OneDrive and Windows Search indexing.

3. Process Supervision:
   If you are launching OmniRoute from a regular PowerShell / Windows Terminal window, closing the terminal or Windows terminal session cleanups will terminate the process. Run with a supervisor or install as a background service:

   npx omniroute doctor
   npx omniroute serve --daemon

Inspect %USERPROFILE%\.omniroute\logs\ and share any error lines if it still occurs!

[jsmithteamiis]

The application is excluded from Windows Defender. I do not use Onedrive. I have a pretty good system so its not resources as an issue. The terminal stays open when omniroute is open. I have noticed that it has happened more consistently after the last Windows update. I can try the daemon method. Before I had upgraded to v3.8.50 I used this method. The omniroute doctor does not show any issues. I have attached the errors from the app.log. There is no gateway.log.
errors_omniroute.log

[diegosouzapw]

Hi @jsmithteamiis. Thanks for the file, it tells us something, but not the thing we need yet.

What it shows: it is a Notepad++ search export of the lines matching "error", not the log itself, so whatever happened right before each drop is filtered out. The one useful trace in it is the (node:<pid>) [DEP0190] DeprecationWarning line, which is emitted once per process: there are 11 distinct PIDs between 09-18 03:09 and 09-20 16:28 UTC, so the server process was started 11 times in that window. None of the error-level lines are fatal; they are all provider failures (OpenCode "Model is unavailable", the Qoder CLI not found, Pollinations credits, one kiro 429) that the router handles per request.

Two corrections to the earlier replies, so you do not chase files that do not exist:

• There is no gateway.log or daemon.log. The layout is %USERPROFILE%\.omniroute\logs\application\app.log (src/lib/logEnv.ts:22) plus %USERPROFILE%\.omniroute\server\crash.log, which is only written when the supervisor gives up (bin/cli/runtime/processSupervisor.mjs:28).
• How you launch decides what you get when the server dies. Plain omniroute serve in a terminal runs a supervisor: it prints Server exited (code=...), restarts, and dumps the crash log when it gives up. omniroute serve --daemon has no supervisor and discards the child's output (bin/cli/commands/serve.mjs:347-370), so a crash there is a silent offline with nothing written. Do not switch to daemon mode to diagnose this.

What I need to find the cause:

1. How you start it: omniroute serve in a terminal, the desktop app, or the tray.
2. When it is "offline", is the node process still alive in Task Manager? Alive but not answering points at a suspended/hung process (Windows power management is a real candidate after an update); gone points at an exit.
3. The unfiltered last ~30 lines of app.log before one of the restarts, for example before 2026-09-20T15:25:47Z or 16:28:24Z.
4. Whether %USERPROFILE%\.omniroute\server\crash.log exists, and its content if so. omniroute doctor prints it too.
5. Anything the terminal printed at the moment of the drop, if it was a terminal.

With 2 and 3 I can usually name it in one pass.

[jsmithteamiis]

How you start it: omniroute serve in a terminal, the desktop app, or the tray. Omniroute is strted in Powershell vi omniroute server
When it is "offline", is the node process still alive in Task Manager? Alive but not answering points at a suspended/hung process Windows power management is a real candidate after an update); gone points at an exit. Node is alive and not answering points.
The unfiltered last ~30 lines of app.log before one of the restarts, for example before 2026-09-20T15:25:47Z or 16:28:24Z.
Log attached
omniroutecrash.log

Whether %USERPROFILE%.omniroute\server\crash.log exists, and its content if so. omniroute doctor prints it too.
Anything the terminal printed at the moment of the drop, if it was a terminal. Nothing printed to the terminal
The omniroute appears to reconnect on its own.

[jsmithteamiis]

This error popped up this time and have never popped up in Omnicopilot chat before

Sorry, your request failed. Please try again.

Client Request Id: f5ecb415-8832-4227-b1d2-abd58a2e7f05

Reason: [g4f-pollinations/community/AkshayCoder48/nvidia-nemotron-3-super-120b-a12b-free] [400]: 400 Bad Request: tools[41]: function.description must be a string ≤ 4096 chars (reset after 2m): Error: [g4f-pollinations/community/AkshayCoder48/nvidia-nemotron-3-super-120b-a12b-free] [400]: 400 Bad Request: tools[41]: function.description must be a string ≤ 4096 chars (reset after 2m) at k.handleSseLine (c:\Users\jsmith.vscode\extensions\diegosouzapw.omnicopilot-1.3.0\dist\extension.js:2:338) at handleSseLine.next () at Async-from-Sync Iterator.next () at k.streamChat (c:\Users\jsmith.vscode\extensions\diegosouzapw.omnicopilot-1.3.0\dist\extension.js:2:75) at processTicksAndRejections (node:internal/process/task_queues:104:5) at U.provideLanguageModelChatResponse (c:\Users\jsmith.vscode\extensions\diegosouzapw.omnicopilot-1.3.0\dist\extension.js:2:7565)

[diegosouzapw]

Thanks, @jsmithteamiis. The log you attached doesn't show the drop, but it does explain the Copilot error, so here are both.

The tools[41]: function.description must be a string ≤ 4096 chars error

That comes from Pollinations: it refuses any tool whose description is longer than 4096 characters. Copilot Chat sends a large tool set, and tool #41 is over the limit. So g4fpol/...nemotron... will never accept this request, whatever its content.

The log shows the fallback that should have followed never ran: 400 Bad Request with body-specific error detected ... skipping fallback to other targets, then stopping combo, with 13 targets left in mycombo. On v3.8.50 the combo stops on any 400 whose text contains "Bad Request" (open-sse/services/combo.ts at the v3.8.50 tag), because the guard was meant for malformed bodies that every provider would reject. A per-provider limit like this one got caught by it too.

#14529, merged into release/v3.8.51 today, replaced that substring check with a decision table (open-sse/services/combo/statusDecisionTable.ts). I ran this exact error text against the current tip. The combo decision is now advance, so it moves on to your next target. The account classification is shouldFallback: false with a zero cooldown, so the Pollinations connection no longer gets parked for 2 minutes over a request-shape error.

Until 3.8.51 is out, move g4fpol/... out of the combo OmniCopilot uses, or down to the end of it. Every Copilot request will hit this limit there.

The "offline" drops

Node staying alive, nothing in the terminal, and the drop clearing up without a restart all point away from a crash and towards the process stalling. I can't tell yet whether that's a blocked event loop or Windows power management suspending it. The attached lines cover 02:42 UTC and contain a normal request, not a drop. To catch one, I need:

1. The approximate local time it went offline and the time it came back.
2. The unfiltered app.log lines from about a minute before the first time to the second. A gap with no lines at all is itself the answer: the process was frozen, not failing.
3. Whether the dashboard at http://localhost:20128 also stopped loading during the drop, or only OmniCopilot showed it as offline.

[jsmithteamiis]

Are there any omnicopilot logs? I will try to get a drop but the logs I grabbed where within 3 minutes of a drop. Is there a debug mode to put the application in? Catching the exact time is relatively difficult down to the second. Either the application reconnects on its own , or I have to reconnect Omnicopilot back to the server.
The dashboard remains up, this is an issue with the omnicopilot losing connection during a request. The console logs do not register any errors, nor warnings at the time. So can you give me a way to bump up the logging, i.e a debug mode for both the server and the chat?

[diegosouzapw]

@jsmithteamiis The dashboard staying up changes the picture. I read how OmniCopilot 1.3.0 decides it is "Offline", and it isn't measuring the server process. That dot flips to Offline in two cases:

• Any chat request that fails. provider.ts in the extension calls onActivity(false) from the request's error path, and the status bar shows Offline immediately. So the Pollinations 400 from your last message counts as "offline" even though the server answered it.
• A health ping that takes longer than 4 seconds. Every 30 s the extension sends HEAD /v1/models with a 4 s timeout (client.ts, ping(timeoutMs = 4000)). If the server is busy, the dot turns Offline without any error on either side.

It only goes back to Online on the next successful ping or request, which is the "reconnects on its own" you're seeing. My best guess is that most of these drops are failed requests, not lost connections. The Output channel below will tell you which one it is each time.

OmniCopilot logs. The extension logs everything to its own Output channel:

1. View → Output, then pick OmniRoute for Copilot in the dropdown.
2. Click the gear icon on that panel (or run Developer: Set Log Level...) and set it to Debug.

Every line is timestamped. You'll see Chat → <model> (N messages, M tools) for each request, Chat request failed: ... with the reason, and OmniRoute connection: offline / online whenever the dot changes. A Chat request failed line just before connection: offline means the drop was a failed request. A bare offline with no failure before it means the ping timed out.

Server debug logging. Set it in the same PowerShell window before starting:

$env:APP_LOG_LEVEL = "debug"
omniroute serve

That makes app.log verbose. It also writes untruncated request/response artifacts (CHAT_DEBUG_FILE switches on with debug), so the files grow fast. Leave it on only until you've caught a drop. Once you have an OmniCopilot timestamp, send the app.log lines from that minute and we can see exactly what the server was doing.

If it turns out to be the ping, you can also check the timeout theory directly. Raise omnicopilot.healthCheckIntervalSeconds in VS Code settings: the dot will flip less often, but a slow /v1/models will still show up as offline lines in the channel.

[jsmithteamiis]

You can close this question

[diegosouzapw]

Closing as you asked, @jsmithteamiis. Thanks for all the detail you put into this.

In short: the OmniCopilot "Offline" indicator also shows up when a request fails or a health ping takes longer than 4 s, and the Pollinations 400 that ended your combo early is fixed in v3.8.51 (#14529). If the drops come back after upgrading, the OmniCopilot Output channel at Debug level shows which of those it was. Open a new discussion with those lines and link this one.