Skip to content

Latest commit

 

History

History
22 lines (19 loc) · 6.07 KB

File metadata and controls

22 lines (19 loc) · 6.07 KB

vibe_cockpit (vc for short)

I want you to help me design a Rust project called vibe_cockpit; the basic idea is this: I use multiple Linux computers to work on dozens of projects using AI coding agents, and I have over 20 Claude Max accounts and over 10 GPT Pro accounts and 5 Gemini Ultra accounts. I need a single TUI dashboard (and also a Next.js dashboard served by the Rust program as an alternative to the TUI) I can watch that shows me how everything is going both on the local machine and on the remote Linux servers using SSH. Luckily, much of this stuff already exists in the form of other existing projects of mine that are part of my agent flywheel system. All projects listed below are my GH public repos and can be found on this machine in the /dp directory: 1. ntm - This is like the nerve center of the agent coding system already. 2. coding_agent_usage_tracker - this project lets me track usage and remaining credit and reset date across all my paid subscription accounts for Claude, GPT, and Gemini. 3. coding_agent_account_manager - this also has some similar functionality with regards to account management and could be useful 4. coding_agent_session_search - this ingests and indexes all the coding agent sessions data on all the machines; it could be very useful for counting the total number of sessions/conversations, tokens, number of compactions, average session length, average session duration in minutes, etc– and all this could be aggregated and viewed by 1) agent type, 2) by machine, 3) GH repo or directory. It could even be configured to track custom things; for example, the number of occurrences of angry curses and insults by the user that might be indicative of the coding agent screwing up! 5. remote_compilation_helper - this lets us offload intense workloads from a main machine to worker machines in a transparent/seamless way so the coding agents don’t even realize it’s happening (things like Rust compilations or bun test suites). Tracking the number and kind of remote compilations in terms of the master machine AND the workers would be very useful. 6. repo_updater - a utility for tracking and syncing a bunch of GitHub repos, useful for easily tracking and counting recent commits and changes but also how much code (in terms of standard LoC and tokens) is uncommitted on dirty repos, on each machine, both the local master machine and the remote machines. This can also be used for tracking number and kind of GH issues and GH PRs, by repo (we can also integrate with the gh utility for this, too). 7. mcp_agent_mail - my agent-to-agent messaging system; would be very useful to track total messages and kinds of messages sent between agents by machine, by repo, etc. Could also look for certain concerning words or phrases in the messages to surface and highlight problems. 8. process_triage - a tool for finding zombie or runaway/broken processes that are impacting system performance and reliability. 9. destructive_command_guard - my pre-tool use hook command checker for Claude Code that checks every command for risky content and blocks the ones that it detects as dangerous. Would be useful to track the number and types of blocked commands over time by machine and by repo. 10. system_resource_protection_script - a script for managing the niceness of processes, could have some useful bits we could steal. 11. rano - a coding agent network observer, useful for measuring network activity, requests, bandwidth going in and out of coding agents like Claude Code, Codex, gemini-cli, etc. by machine. Could be useful for surfacing problems early. 12. beads_viewer - (aka, bv) a utility for tracking beads, the task management system I use for everything. This is incredibly important because it helps quality progress on the projects; knowing the average length/complexity of beads and being able to track how many beads are worked on and finished hour by hour and day by day across all my repos, agent instances, machines, etc. is incredibly valuable. 13. beads_rust - (aka, br) this is the actual beads program that can also be useful, although beads_viewer might be better suited for integration into this project (but more likely is that we need to integrate with both bv and br to get all the relevant information) 14. automated_flywheel_setup_checker - this is a new project for verifying that my agentic_coding_flywheel_setup project’s acfs script is working properly and doesn’t have catastrophic problems like manifest checksum mismatches that prevent it from working. 15. cloud_benchmarker - this is a benchmarking and monitoring tool I made for VPS instances; it has a lot we can use.

In addition to pulling all this data in every few minutes from all sources and all machines and putting it into a DuckDB database for analysis, aggregation, filtering, anomaly detection, forecasting, visualization, we can also use this data for alerting. The idea is to help me manage this empire of hundreds of agents and multiple machines so I can debottleneck and automate things. This vc project would itself have a “robot mode” for coding agents that want to interact with this so they don’t need to use the TUI but can instead access all the same functionality via a CLI in the console that is hyper-optimized and ergonomic for agents while also being ultra-intuitive for coding agents like yourself; the agent users should get back as output either JSON or Markdown (whatever fits best in the context and is most token-efficient and intuitive for you). Basically, the agent users should get all the same information as a human could get from manipulating and visually observing the TUI, but in a more usable, accessible form for agents. Make the tooling here that YOU would want if YOU were using it (because you WILL be!).

And the end goal is to have Claude Code or Codex watching this thing on a sleep/wake cycle every couple minutes, and when it sees something bad happening in any way, connecting with SSH or directly on the local machine, investigating and diagnosing and triaging the problems to get things “unstuck”. That might include swapping to a new Claude Max account proactively, freeing up disk space, etc.