Sizing & Hardware

How much machine VibeCody needs, and where it goes. Two kinds of number appear on this page and they are kept apart on purpose:

• Measured — taken from a run in this repository, with the source or the harness named. Trust these.
• Estimated — arithmetic from parameter counts and quantisation, or a vendor’s published figure. Useful for planning, wrong in the third decimal place. Every estimate says so.

Nothing here is a benchmark of your hardware. vibecli --setup reads the machine in front of it and recommends from that.

The short answer

The daemon itself is small. Nearly everything on this page is about the models you choose to run beside it. A daemon pointed at a cloud provider will run comfortably on a Raspberry Pi.

What the setup wizard already decides

vibecli --setup detects OS, architecture, RAM and GPU, then picks a deployment tier and a local model. This is the policy in vibecli/vibecli-cli/src/setup.rs, not a recommendation invented for this page:

Tier, from system RAM

Those tier names reach the deployment templates. On Oracle Cloud (deploy/oracle-cloud/main.tf) they resolve to:

Local model, from system RAM

Two things to know about that table. A machine with 32 GB or more is sent to a cloud model, not a larger local one — the same answer it gives a machine with under 8 GB, for the opposite reason. And the wizard’s GPU detection does not feed this decision at all: detect_gpu() fills in a field that is printed for you and never read by recommended_model(). On a box with a small system RAM and a large discrete GPU, or the reverse, size it yourself from the tables below rather than taking the wizard’s word.

GPU: what actually needs one

Three separate workloads can use a GPU, and only one of them usually matters.

If you use cloud providers only, you do not need a GPU at all. Nothing in the agent loop, the editor, the review pipeline or the skills system is GPU-accelerated, because none of it is arithmetic on tensors.

What VibeCody can drive

Estimating VRAM for a local model

Estimated, not measured. Weights dominate, so the first approximation is parameters × bytes-per-weight, and the quantisation picks the second term:

Weights alone, rounded:

† Measured, not estimated: bartowski/SmolLM2-360M-Instruct-GGUF’s SmolLM2-360M-Instruct-Q4_K_M.gguf is 270,590,880 bytes (258 MiB / 0.27 GiB). No chat model ships inside the desktop installers as of 2026-09-18 — see providers/vibecli-mistralrs for the current zero-config default and how it’s fetched. It’s a pre-quantized file, not a Q4_K_M-quantized-at-load fp16 file, so its own row has no meaningful measured FP16/Q8_0/Q5_K_M cells — those three are still the estimation method above, unverified, same as every other cell in this table.

Then add context. The KV cache grows with the context you actually use, and it is not small at long context — budget 1–2 GB on top for ordinary use, and considerably more if you intend to fill a 128k window. A 7B at Q4_K_M wants roughly 6 GB of VRAM in practice, not 4.2.

On Apple Silicon the GPU shares system memory, so “VRAM” is your RAM, minus what macOS and everything else is using. A 16 GB Mac runs a 7B at Q4 comfortably and a 13B at Q4 tightly.

VRAM is a cliff, not a slope. A model that fits runs at GPU speed; one that overflows by a little spills to system memory or CPU and can get dramatically slower — not a few percent. Size to fit, then raise quality.

Voice, speech in and out

Voice is the one subsystem where this repository has real measurements. From Full-duplex voice:

Measured, on an M-series MacBook Air:

The model is nearly all of the latency. Recognition is well under a second and speech is milliseconds; a large model is seconds of silence. This is why Settings → Voice can pin a small model for spoken replies independently of the one the composer uses for writing code.

Disk, from WhisperModel::size_mb in vibecli/vibecli-cli/src/voice_local.rs:

small and medium were measured to produce identical correct text on non-Latin input, and small is about 3× faster — start there.

Text-to-speech: the platform engine costs nothing and needs no download. Kokoro is a 82M-parameter neural model — negligible next to any LLM, and Apple Silicon only. See Choosing a voice engine.

Embeddings and the code index

Disk is the cost, and it is predictable. Each index is roughly:

chunks × dimensions × 4 bytes

A 768-dimension model such as nomic-embed-text is therefore ~3 KB per chunk. Ten thousand chunks is about 30 MB. Dimensions are per-model and configurable — see Embeddings.

Building an index is a burst of CPU or a burst of API calls, depending on the provider. It is not a standing cost, and it is not a reason to buy a GPU.

Per-target recommendations

Desktop, one person

The desktop apps start the daemon themselves. Nothing to size separately.

Always-on server

Oracle Cloud’s always-free 4 ARM cores + 24 GB fits the second column at $0 — see Deployment guides.

Raspberry Pi

A Pi pointed at a cloud provider is a fine always-on daemon and RAM stops mattering. Local inference on a Pi is a demonstration, not a workflow.

Two costs that are not hardware

A cold daemon has been measured at ~16 s to first answer /health. That is not slow hardware; it is startup work. It matters for serverless platforms that scale to zero, and it is why nothing in this codebase may sleep a fixed guess and then check once.

Context windows come from the provider, not from your RAM. Each model’s budget is read from its vendor’s API. See Configuration.