What Is Your Repository Actually Made Of?
A local repository is rarely just source code.
Over time, it becomes a mix of source files, Git history, dependencies, generated build output, caches, logs, assets, local databases, framework artifacts, and tool-specific folders.
That makes project size surprisingly hard to reason about.
When a repo grows to 10 GB, 30 GB, or more, the first question should not be:
“What can I delete?”
It should be:
“What is this project actually made of?”
That idea became Projects in Room Service.
Projects gives local development folders their own workspace. It scans repositories and breaks them down into meaningful groups like Git data, dependencies, build outputs, caches, assets, logs, and source files, so developers can understand project structure before making cleanup decisions.
This becomes especially useful in monorepos, long-running client projects, game development folders, and AI-heavy environments where generated artifacts quietly grow over time.
The goal is not to treat repositories like random folders.
It is to make local development environments easier to understand.
I’m curious how other developers handle this today:
When a local repo becomes huge, do you inspect it manually, rely on terminal commands, rebuild from scratch, or mostly ignore it until storage becomes a problem?
Replies
Most teams probably live in the "ignore it until disk space screams" phase
Breaking repo size into meaningful buckets instead of just showing one giant number feels much more actionable ,
especially for monorepos and AI projects where cache/build artifacts explode quietly.
@suolar_ I mostly use terminal commands today, but they become noisy fast in large projects. A repo might look huge while most of the space is actually generated output or package caches.
@suolar_ @henry_lindsey I’ve noticed AI workflows make this problem much worse. Model downloads, embeddings, generated datasets, and local vector stores quietly explode repo size