The GPU/compute telemetry feels a little too superficial for an IDE whose whole premise is running agents in parallel. Once you have ~10–15 concurrent sessions across machines, I’d really want per-agent resource attribution rather than just aggregate CPU/RAM/GPU stats. Ideally something like GPU utilization, VRAM consumption, process-level memory, thermal throttling, and inference/compute saturation over time.
The other thing I’ve noticed is that the spatial canvas starts becoming its own resource-management problem at scale. A 2D representation is great for reducing context switching, but once you have dozens of terminals emitting high-frequency updates, the UI needs aggressive virtualization/backpressure or you end up trading terminal-tab chaos for rendering/event-loop contention.
Would also love configurable polling intervals + event-driven telemetry instead of periodic system metrics, and some kind of resource budget per agent so one runaway process doesn’t starve the rest of the workspace.
Welcome to StartupBase
Join a community of founders sharing their products and discovering what others
are building.
Email sign-in is for existing accounts. New here? Use Google, LinkedIn, or X above
— your account is created automatically.
Continue with email
Enter the email address on your existing account and we'll send you a one-time
sign-in code. This does not create an account — to sign up, go back and
continue with Google, LinkedIn, or X.
Enter the verification code we sent to your email address.
Continue with Google
Continue with LinkedIn
Continue with X
The GPU/compute telemetry feels a little too superficial for an IDE whose whole premise is running agents in parallel. Once you have ~10–15 concurrent sessions across machines, I’d really want per-agent resource attribution rather than just aggregate CPU/RAM/GPU stats. Ideally something like GPU utilization, VRAM consumption, process-level memory, thermal throttling, and inference/compute saturation over time.
The other thing I’ve noticed is that the spatial canvas starts becoming its own resource-management problem at scale. A 2D representation is great for reducing context switching, but once you have dozens of terminals emitting high-frequency updates, the UI needs aggressive virtualization/backpressure or you end up trading terminal-tab chaos for rendering/event-loop contention.
Would also love configurable polling intervals + event-driven telemetry instead of periodic system metrics, and some kind of resource budget per agent so one runaway process doesn’t starve the rest of the workspace.