onWatch solves a problem I have felt myself: AI coding tools show a live usage snapshot, but developers need the historical, per-cycle, cross-session view to avoid surprise throttling mid-task and to plan budgets. Polling a dozen-plus providers in parallel from a sub-50 MB background daemon, then projecting burn rate with live reset countdowns in one dashboard, is exactly the workflow that was missing. The zero-telemetry, single-binary, all-data-local design also makes it trustworthy enough to leave running.
Because onWatch already treats API-key platforms, including OpenAI-compatible gateways like OpenRouter, as first-class sources, its .env-driven provider abstraction fits another gateway naturally. Developers who front their AI tools with one routing endpoint could see that usage beside every other provider they already watch, which is the budget-tracking workflow onWatch serves.
I'm an engineer on the OrcaRouter team, and I'd like to propose adding OrcaRouter as an optional, trackable source for onWatch. This would not replace or alter any existing provider integration; it would sit alongside the sources you already support.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. A few of its capabilities map directly onto the problems onWatch addresses:
- Unified usage tracking and budgets across the models routed through one OrcaRouter account, matching onWatch's spend-visibility goal for API-key platforms.
- Automatic model routing with provider failover, which reduces the mid-task throttling interruptions that onWatch alerts people about.
- Team access controls, which matter for the small shared-key teams (3-20 people) in onWatch's stated audience.
Following the per-provider pattern documented in CONTRIBUTING.md and CLAUDE.md - a client under internal/api/, an env key in .env, a tracker/agent, and a dashboard tab - the natural shape would be an ORCAROUTER_API_KEY-backed source, and the repo's provider list already includes OpenRouter, another OpenAI-compatible gateway, so the pattern is proven. Nothing here is implemented or tested yet; this is a proposal to gauge interest before any code is written.
OrcaRouter is already integrated with open-source projects in the AI tooling space, including goose, OpenCode, and promptfoo, and integrations are listed at https://www.orcarouter.ai/built-with.
One transparent note: OrcaRouter runs an optional open-source partner program in which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for an integration, and we would fully respect onWatch's disclosure and governance expectations either way.
Would adding OrcaRouter as an optional source be of interest? I would welcome your feedback, and with the go-ahead I'd be glad to submit an implementation PR following onWatch's TDD-first workflow (./app.sh --test, go vet ./...).
onWatch solves a problem I have felt myself: AI coding tools show a live usage snapshot, but developers need the historical, per-cycle, cross-session view to avoid surprise throttling mid-task and to plan budgets. Polling a dozen-plus providers in parallel from a sub-50 MB background daemon, then projecting burn rate with live reset countdowns in one dashboard, is exactly the workflow that was missing. The zero-telemetry, single-binary, all-data-local design also makes it trustworthy enough to leave running.
Because onWatch already treats API-key platforms, including OpenAI-compatible gateways like OpenRouter, as first-class sources, its
.env-driven provider abstraction fits another gateway naturally. Developers who front their AI tools with one routing endpoint could see that usage beside every other provider they already watch, which is the budget-tracking workflow onWatch serves.I'm an engineer on the OrcaRouter team, and I'd like to propose adding OrcaRouter as an optional, trackable source for onWatch. This would not replace or alter any existing provider integration; it would sit alongside the sources you already support.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. A few of its capabilities map directly onto the problems onWatch addresses:
Following the per-provider pattern documented in CONTRIBUTING.md and CLAUDE.md - a client under
internal/api/, an env key in.env, a tracker/agent, and a dashboard tab - the natural shape would be anORCAROUTER_API_KEY-backed source, and the repo's provider list already includes OpenRouter, another OpenAI-compatible gateway, so the pattern is proven. Nothing here is implemented or tested yet; this is a proposal to gauge interest before any code is written.OrcaRouter is already integrated with open-source projects in the AI tooling space, including goose, OpenCode, and promptfoo, and integrations are listed at https://www.orcarouter.ai/built-with.
One transparent note: OrcaRouter runs an optional open-source partner program in which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for an integration, and we would fully respect onWatch's disclosure and governance expectations either way.
Would adding OrcaRouter as an optional source be of interest? I would welcome your feedback, and with the go-ahead I'd be glad to submit an implementation PR following onWatch's TDD-first workflow (
./app.sh --test,go vet ./...).