How Much Disk Space Do AI Coding Assistants Actually Use? We Checked.

Every AI coding tool gets lumped into the same vague complaint — "these things eat disk space" — but that's not equally true of all of them, and treating them as one category leads to the wrong cleanup decisions. Some AI coding assistants run entirely against a cloud API and leave behind little more than logs and a small local index. Others actively index your whole codebase into a local vector store, or bundle an optional local completion model, and those genuinely do add up.

We looked at what each of the common tools actually writes to disk on macOS — not what they claim, what's actually sitting in Application Support and Caches after normal use across a handful of active projects over several weeks.

Sizes below are typical ranges after a few weeks of regular use on a handful of active projects, not worst cases:

The split isn't really about which company made the tool — it's about whether inference happens locally or against an API. Copilot, Cody, and Codeium keep almost nothing on disk because the model doing the work isn't on your machine at all. Cursor and Windsurf sit in the middle: their chat inference is cloud-based too, but both build and maintain a local semantic index of your codebase to support features like multi-file context, and that index is real, ongoing disk usage that scales with how many projects you keep open in them. Tabnine and any setup using Continue or Aider with a local model are the only cases here where you're storing actual model weights, and that cost is identical to running Ollama or LM Studio directly — because in most cases, that's literally what's underneath.

It helps to know what's inside that 1-4GB Cursor or Windsurf figure, since "index" undersells how much is actually stored. When you open a project, these tools chunk your source files (usually by function or logical block rather than fixed line counts), generate an embedding for each chunk, and store both the vectors and enough metadata to map a match back to a specific file and line range. For a mid-size codebase — say 50,000 lines across a few hundred files — that can produce tens of thousands of chunks, and the resulting index commonly lands between 200MB and 800MB per project depending on chunking granularity and whether the tool also caches parsed syntax trees for faster re-indexing.

The part that surprises people: this index is retained per project, and reopening a project after weeks away doesn't discard the old index — it either reuses it or updates it incrementally. That means a developer who's opened even fifteen or twenty different repositories in Cursor over six months — including short-lived clones, tutorial repos, and abandoned side projects — can be storing that many separate multi-hundred-megabyte indexes simultaneously, most of which will never be opened again.

Tabnine is worth calling out specifically because its footprint is bimodal rather than a single consistent number. In its default cloud configuration, it behaves like Copilot — tens of megabytes, mostly logs and settings. Switch it to local or air-gapped mode, intended for teams with strict code-privacy requirements, and it downloads a dedicated completion model sized for on-device inference, commonly in the 1-4GB range depending on the model tier selected. That model lives under Tabnine's own Application Support folder rather than in an Ollama or LM Studio store, which means it's easy to miss during a general AI-cache audit if you're only checking the well-known model runners.

Everything above assumes reasonably normal-sized projects. Monorepos change the math meaningfully, because a codebase index generally scales with total file count and code volume in the workspace, not with how much of it you actually touch day to day. A monorepo containing a dozen services, each with its own dependency tree checked into the repo or vendored locally, can push a single project's index well past a gigabyte on its own — closer to the size of two or three ordinary projects combined. If you work primarily in one or two monorepos, it's entirely possible for those alone to account for most of Cursor's or Windsurf's total footprint, with every smaller side project contributing only a rounding error by comparison.

This also means the per-project index size isn't a reliable signal of how large the underlying source actually is, since most of these tools exclude common non-source directories (node_modules, build output, .git) from indexing by default — but not always consistently across every language and monorepo layout, so it's worth spot-checking a large project's index size against what you'd expect from its source alone if the number looks surprising.

It's worth being precise about the "tens of MB" figure for cloud-inference tools like Copilot, Cody, and Codeium, since "small" can still mean different things. In practice this usually breaks down into a rotating extension log (a few MB, capped and overwritten rather than growing indefinitely), a small telemetry queue of usage events waiting to be sent or already sent, and cached completion suggestions kept briefly for the current session. None of these categories is designed to accumulate — they're either capped by the extension itself or cleared on VS Code restart — which is the real reason these tools stay small over time rather than just starting small and growing slowly. That's a structural difference from Cursor's or Windsurf's index, which is explicitly designed to persist and grow as you use more projects.

A few commands to see what your own setup is actually holding:

Of everything covered here, the codebase index that Cursor and Windsurf maintain is the one most likely to surprise you, because it grows quietly in the background every time you open a new project, and it isn't cleared when you close a project — only when you explicitly remove it or uninstall the app. If you've opened dozens of repositories in Cursor over several months, some of them abandoned side projects, that index history is a real and recoverable chunk of space. A useful gut check: if your Cursor Application Support folder is larger than 2-3GB and you can't name more than five or six projects you've actively worked in during the last month, most of that size is likely stale project indexes rather than anything currently useful.

If you're trying to free up space and you're using Copilot, Cody, or Codeium, there's not much to reclaim there — they were never the source of the bloat. If you're using Cursor, Windsurf, or Tabnine's local mode, or you've configured Continue or Aider against a local model, that's where to actually look, and in the last case, cleaning up is really about managing your Ollama or LM Studio model store rather than the coding extension itself. Knowing which category your setup falls into before you start deleting things saves you from clearing a tiny extension cache and being disappointed, or from ignoring a multi-gigabyte index because you assumed all AI coding tools were equally lightweight.