Reference
Choose a project your computer can handle.
Preparing a project takes time, memory and disk space. These examples show what was measured on particular machines. Start small and check the requirements before importing your code.
How this works in Kin
These import and query measurements come from named repositories, builds and machines. They describe those runs; later operations can still require more time, memory or disk.
How to read these
Every figure is an observation from one run, not a forecast for yours. Import cost tracks history depth and file count rather than checkout size, so two repositories of the same size on disk can differ by an order of magnitude. Start small, watch the first one, then decide.
Peak memory, by run
View the memory measurements
New project, built from scratch
2.81 GiB peak
A markdown notes app written on Kin from an empty directory: 1,689 lines of Python across five modules, 116 tests passing and seven commits.
Graph at capture: 210 entities and 407 relations, in a 2.6 MiB store. The container never reached its own cap.
Version control with no Git under it
Not re-measured on v0.7.2
15 changes, two branches, two merges, one of them a same-function conflict driven to publication, and four kinds of undo, each checked by hashing the affected files.
The v0.6.7 session peaked at 2.55 GiB in its second phase. Nobody memory-profiled the v0.7.2 session, so that figure is the last measurement and is dated here rather than restated. What the v0.7.2 session did produce is a Git export of 17 commits and 4 refs.
Two existing Git repositories imported
Within 76 KiB of the 12 GiB ceiling
psf/requests and express 5.2.1, brought in from their Git history.
The first kin commit on requests, a 22-line docstring edit, held the container there for 191 seconds. No daemon was killed. The kernel reclaimed instead, 27,064 allocation stalls, and the commit exited 0.
Time
View the time measurements
The five-command path in the README
18 seconds end to end
On body-parser, during the release proof.
kin init on a 503-file repository with 1,983 commits
139 seconds
Fresh Debian 12 container, 4 CPUs, 8 GiB. The installer leg took 4 seconds.
The first kin locate on that repository
6.7 seconds while the daemon cold-started
The README records a much faster warm figure and is explicit that these are separately measured legs of one sitting, not one timed run.
kin init on psf/requests
14m54s
Debian 12 on aarch64, 12 GiB, five-CPU quota, on the public v0.7.2 archive. No language server was installed yet, so cross-file enrichment is not in that number.
kin init on express 5.2.1
8m46s
Same container, with the Python and TypeScript language servers installed first. The two were run that way on purpose, as a controlled pair.
kin init on an empty directory
About one second
The greenfield run. The Git-free ledger in the version-control run took about half a second.
First commit on a cold daemon
Just under four seconds
Greenfield run. Warm commits came back in well under a second.
A first full index and embed pass
Roughly 20 minutes and up to 7 GB of memory
Measured once and not repeated since. Name-mode search starts answering about two minutes after kin init begins. No run in the v0.7.2 proof re-measured this one, so it stands as it was.
Disk
View the disk measurements
psf/requests store
1.7 GiB
783 entities and 5,302 relations across 130 files.
express 5.2.1 store
923 MiB
380 entities and 1,639 relations.
The embedding model
Roughly 523 MB
Downloaded once, on first full embedding.
kin status reports your own store size beside the Git object store it came from, and says in the same breath that the ratio varies widely between repositories, because store size grows with history depth rather than with checkout size.
What happens when memory runs short
Kin puts a ceiling on a repository daemon rather than letting it take what the host has, and it holds work back rather than failing the command. One repository daemon is allowed at most 8 GiB whatever the machine has spare, a second repository gets its own daemon and its own ceiling, and background embedding is the first work held back once a daemon's share is spent.
Two kin doctor rows report this while it is happening: a memory standing row saying how much of its ceiling this daemon holds right now, and a host memory pressure row saying whether any work on this store has been held back for want of memory. Read those two before concluding that an import has stalled.
Checked here on Kin v0.7.6 on 2026-09-09. Current release: v0.7.19.
What has not been measured
- Disk or memory on macOS. The v0.7.2 install proof ran on macOS and timed every step, but an install proof measures install, not footprint.
- Disk or memory on Windows, native or under WSL2.
- Anything larger than psf/requests. Performance at scale was not measured.
- The filesystem projection. kin-vfs ships in the public Linux and macOS archives and no run exercised it. On v0.7.2 the macOS install proof read the shim as installed and the driver as running, which is a readiness row rather than a use of it.
- Footprint on a machine with more than 12 GiB available. Every run above was capped at 12 GiB.
Next action
Pick a first repository you can afford to wait on.
Something with a few hundred files and a history you do not mind importing twice. The Git page walks the admission and shows what comes in with it.
Try Kin alongside Git