A free VRAM calculator for AI models. Not just for LLMs: text generation,
embeddings, vision, multimodal, image diffusion, video, audio, and tabular
workloads, across inference, LoRA/QLoRA fine-tuning, and full training.
Static Vite + TypeScript. Every calculation runs in the browser. No backend,
no ads, no signup, no tracking. The formula, per-component breakdown, and
assumptions behind every estimate are shown in the UI, and recommendations are
measured against usable VRAM (advertised capacity minus the driver/CUDA
reserve), not the sticker number.
Based on the (more mature) Python ralph agent harness
Supports
- text generation, embeddings, encoder-decoder, vision, multimodal
- image diffusion, video, audio, tabular, and custom workloads
- inference, LoRA, QLoRA, and full-training estimates
- known model file size overrides, MoE, sharding, and runtime assumptions
Calculates
- usable VRAM required
- recommended hardware memory tier
- minimum advertised GPU capacity
- usable target, headroom, rough speed, formula, and assumptions
Core equation:
Required_GB = (Weights + Working_Memory + Training_State + Runtime_Overhead) * Buffer
Estimates vary with model architecture, kernels, quantization, sequence packing,
batching, sharding, offload, framework overhead, and runtime configuration.
Validate against your target stack before buying hardware.
Run Locally
pnpm install
pnpm setup
pnpm dev
Build
pnpm build
pnpm preview
Profiling note: Always run Lighthouse against the production preview
(pnpm build && pnpm preview, served on 127.0.0.1:4183), never the dev
server (pnpm dev, 127.0.0.1:5174). The dev server serves raw unbundled
modules over an HMR WebSocket, so a report taken there shows unminified JS,
unused zod, no-bf-cache, and a large CLS from the serialized module
waterfall — all dev-only artifacts, none of which exist in the deployed
build. harness/lighthouserc.cjs already targets preview for this reason.
Development Checks
# checks
pnpm preflight
pnpm gate
pnpm --prefix frontend run test:coverage
pnpm --prefix frontend run test:e2e
Key Files
- UI:
frontend/index.html and frontend/src/app.ts
- State:
frontend/src/state.ts
- Calculation:
frontend/src/calculator-core.ts, frontend/src/workload-memory.ts
- Hardware tiers:
frontend/src/hardware.ts
- Report assembly:
frontend/src/report.ts
- Specs:
specs/plan.md, specs/qa.md
Requirements
Why build this
Without a real app in production a harness cannot be trusted. This app was developed alongside L∞pGate JS to learn from (painfully) and serve as v0 proof. As a fan of dev tooling, meta-absuridism, and cycles, building the most deterministic self-referential Ai tool conceivable on the fly (an AI GPU calculator) all while building a looping harness just felt right.
Generally, frontend work has a messy non-deterministic contract. Yet an app must remain accessible/build/render/respond/fit across viewports and loading paths. AND have ✨taste✨. UI has a gradient of quality and Agents stop ASAP unless forced to improve. That's why this heavy WIP harness is here. With web we don't get simple deterministic outcome like with a Python harness. A frontend agent can pass tests while shipping a blank page. So the loop is strict on purpose The harness uses tooling to force an agent to build an app to look like a human did. These checks cover different failure modes:
- TS, HTML, CSS, JSON format
- lint
- types
- architecture
- dead code
- security
- build
- unit coverage
- e2e Playwright
- Lighthouse must be 100
- preferences.ts checking for smells that an app is not responsive...
- etc.
Agents struggle more with frontend for structural reasons. They can reason over code, but frontend correctness is not simply in code text. It is the interaction between:
- generated HTML
- bundled JS
- CSS cascade
- layout engine
- viewport size
- browser defaults
- assets
- async hydration
- events
- accessibility tree
- CSP/headers
- performance timing
A backend bug has a crisp functional target, e.g. this function returns wrong value. A frontend issue often says without words: “the thing looks wrong”. Agents need heavy tool feedback to 'see' issues or they are guessing from source. loopgate_js harness doesn't promise to fix all of the above. It is a first attempt to expose some and enforce that agents make fixes.
