-
-
AgentFit shows safe active concurrency separately from an empirical accumulated-thread estimate.
Inspiration
Coding agents make it easy to fan work out across many subagents, but the practical question, “How many can my machine handle?”, is usually answered with a guess. During an approximately 21-hour run on a 24 GB Mac, 160 direct child threads accumulated over time while the workloads actually active at once were far fewer. That exposed a dangerous ambiguity: logical threads accumulated over time are not the same thing as memory-heavy jobs running simultaneously.
I built AgentFit to make that distinction explicit and give developers a transparent starting point before they overload a machine or mistake swap-backed endurance for safe concurrency.
What it does
AgentFit turns total RAM and a workload preset into two clearly separated capacity models:
- Safe active concurrency for light, balanced, or heavy coding-agent workloads.
- Safe, balanced, and maximum levels so users can choose a risk margin.
- An empirical extreme accumulated count scaled from the observed 24 GB / 160-thread run.
- Estimated swap and combined memory for interpreting that extreme case.
- Adjustable system reserve for people who need to leave more memory for other apps.
- Optional browser RAM detection, with manual input kept authoritative.
Every result is calculated locally in the browser. There is no sign-up, install, backend, or uploaded machine data.
How we built it
AgentFit is a static, dependency-free web application built with semantic HTML, modular CSS, and vanilla JavaScript. The calculation engine lives in a pure ES module so its formulas and validation rules can be tested independently with Node's built-in test runner.
The active-concurrency model first reserves memory for the operating system and other apps, then one main agent, and divides the remaining pool by the selected per-agent workload. The interface presents 65% of the memory-only maximum as Safe, 85% as Balanced, and the unbuffered value as Maximum.
The empirical model scales a documented 24 GB benchmark that reached 21.69 GB of swap and accumulated 160 unique child threads. The UI repeatedly labels this as an accumulated estimate, not a simultaneous-concurrency recommendation.
The public GitHub star count is loaded through Shields.io's cached JSON endpoint with a GitHub API fallback. If both fail, the calculator still works and simply omits the count.
Challenges we ran into
The biggest challenge was preventing a technically true number from becoming a misleading recommendation. “160 subagents” sounds like 160 concurrent builds or browsers, but the source run represented accumulated logical threads with much lower overlap. The product copy, visual hierarchy, and two-model architecture all had to reinforce that difference.
Browser RAM detection was another constraint: support is inconsistent and Chromium may reduce precision. AgentFit therefore treats detection as optional and keeps explicit manual input as the source of truth.
Finally, we wanted a polished, accessible product without a framework or build pipeline. That meant careful semantic structure, keyboard-friendly controls, responsive layouts, dark-mode support, and resilient behavior when external star-count services are unavailable.
Accomplishments that we're proud of
- A working, zero-install calculator that judges can test instantly.
- Transparent formulas instead of a black-box recommendation.
- A clear separation between safe simultaneous work and extreme accumulated threads.
- Automated tests for formulas, boundaries, validation, and API response handling.
- An accessible interface that works across light and dark color schemes.
What we learned
Agent capacity cannot be represented by one headline number. Lifetime overlap, memory intensity, swap, CPU, provider limits, and task duration all matter. The safest product decision was to expose the assumptions and make uncertainty visible rather than hide it behind false precision.
What's next for AgentFit
Next, I want to add benchmark profiles from more machines, CPU- and provider-aware limits, shareable result links, and an export format that agent orchestrators can consume directly. More real-world measurements will also make the empirical model less dependent on a single machine and workload.
Log in or sign up for Devpost to join the conversation.