Project limits
Every ceiling in one place - projects, files, bytes, history and restore points - including the two file-size limits that are deliberately different.
If you have run out of space, hit a limit, or been told a project is too large, the numbers are here. You can have 20 projects, each holding up to 60 files and 256 KiB of source. A single file can be 100 KiB stored but only 64 KiB run. Every ceiling is below.
| Limit | Value |
|---|---|
| Projects per account | 20 |
| Files per project | 60 |
| Total source bytes per project | 256 KiB |
| Bytes per file, stored | 100 KiB |
| Bytes per file, run | 64 KiB |
| Run history kept | 50 runs |
| Restore points kept | 20 |
The two file-size limits are not a mistake#
A file can be stored at up to 100 KiB but only run at up to 64 KiB. Those answer different questions and the gap is deliberate.
Importing a repository legitimately brings in a file bigger than the runner will accept - a generated file, a big fixture, something nobody intends to execute. Refusing to store it would fail the entire import over one file that does not matter.
Why 60 files#
The sandbox writes every file in the project into its box and hands all of them to the compile stage, and the container caps open files at 128. Sixty is a measured ceiling with room to spare, not a round number.
What does not count#
- Linked Canvas boards (
.rqd) carry no drawing data. - Binary assets stored outside the project's text storage.
Source files are what the byte budget measures.
Hitting a limit#
Nothing is deleted to make room and nothing silently truncates. The action that would exceed a ceiling is refused and tells you the limit and what the result would have been - so "60 files, this would be 61" rather than a generic failure.
If you are at the project cap, archive rather than delete. Archived projects keep their files, history and share links.
Was this page helpful?