"Usage" sync agent?

[gltched-usr]

okay I just had this idea and maybe its verry dumb.

But since the "remote" version doesn't really support stuff like multi user for codex and codex tokens sometimes expire I have the following idea: Why not have some kind of lightweight agent you can run on your pc? And if an agent is connected it "collects" the usage locally but sends it to the "remote" docker version? Then you could throw the agent on every pc you use and no need to manually update tokens.

Like just a few mb agent that autostarts and is under the windows serveices? Maybe a small tray icon for settings etc?

[gltched-usr]

Maybe little bit like beszel agent?

[prakersh]

This is a great idea - the hub + agent architecture (like beszel) is exactly the right pattern here.

We actually already have a menubar companion that runs as a lightweight background process on macOS, and we're working on porting it to Linux in #35 (GTK3 + WebKitGTK).

The plan would be to extend this into a full sync agent - so it's not just a local display, but also:

• Token collection - agent watches local credential files (Codex, Gemini CLI, etc.) and syncs them to the central Docker instance, so no manual token updates or env var management
• Usage reporting - forwards locally observed usage to the hub
• Menubar/tray UI - shows real-time consumption right in your system tray (already working on macOS, Linux coming via feat: Linux menubar companion (GTK3 + WebKitGTK) #35)
• Multi-machine - run it on every machine, everything reports to one dashboard

So basically a morph of the menubar companion (#35) into a hub+agent setup. The menubar becomes the agent's UI.

This is a significant addition though - networking, auth, and the hub API need to be designed carefully. It'll take time to get right, but it's definitely on the roadmap.

What's the biggest pain point for you right now - token expiry, multi-machine sync, or the 429 issue from #32? That'll help scope what to tackle first in a v1.