CBX is the repository technology
CBX defines lossless project manifests and version content,.cbx exports, content-defined chunks, tiny-file packs, compression, deduplication, resumable transfer and byte-exact restoration.
WHY
Two things, and the reasons for each
CodeRook is the platform. CBX is the repository technology it runs on — the same relationship GitHub has with Git. Each is an alternative to something different, so each is argued separately: CBX against Git, Git LFS, Git Xet and Perforce, measured in bytes; CodeRook against the git forges, on the choices they each made. Both sections say what the comparison does not show.
THE PROBLEM
One project needs one lossless content path
A working project can contain source code, model weights, media, generated assets and thousands of small files. Git is excellent at distributed text history, but common large-file workflows add another object store while Git continues to record the repository transaction. CBX solves the content side of that problem: it can represent a complete folder losslessly, move only missing content during an authenticated thin transfer, and reconstruct every byte. CodeRook builds the hosted Version, Track and publication workflow on that CBX foundation.
PLATFORM + REPOSITORY TECHNOLOGY
CodeRook and CBX are designed to work together
CodeRook is the hosted platform
CodeRook uses CBX to power complete Versions and project transfer, then adds accounts, projects, Tracks, Change Requests, Merge Tracks, permissions, policies and collaborative web, desktop and CLI surfaces.
Git owns compatibility operations
Git remains available for import, export and proven low-level operations where useful. Temporary Git workspaces are disposable; they are not CBX archives and they are not the authority for CodeRook’s hosted history.
The relationship is comparable to GitHub and Git: the platform and the underlying repository technology are distinct, but the platform is built around using that technology. CBX is not a minor feature bolted onto CodeRook. It is the project-data foundation CodeRook uses for portable bundles, live publication and restoration.
PLATFORMS, NOT PROTOCOLS
CodeRook and the git forges made different bets
The benchmarks further down compare CBX with Git, Git LFS, Git Xet and Perforce, which are technologies. This compares CodeRook with the places people actually keep projects, which is a different question with no number to settle it. So each one below gets what it is genuinely best at and what that choice costs — there is no column of ticks, because a reader can weigh a trade-off and cannot check a tick.
| Platform | What it is built around | What that costs |
|---|---|---|
| GitHub | The ecosystem. Every CI system, editor, review tool and hiring manager already speaks it. | The repository model is Git's, so binary-heavy and very large projects are handled by bolting LFS underneath. |
| GitLab | One product for the whole pipeline — issues, CI, registry, deployment — and it can be self-hosted. | A large surface to run and keep current, and seats are priced per person as a team grows. |
| Bitbucket | Close coupling to Jira and the rest of Atlassian's tooling. | Worth most to teams already inside that suite, and comparatively little outside it. |
| Codeberg | A non-profit with no commercial interest in what you store, funded by members. | Deliberately small in scope and volunteer-run, so there is less around it. |
| CodeRook | Deciding: what is offered, what is held back, and what machines may do with it. Priced on stored bytes rather than seats. | New, and the tooling around it is ours alone. There is no twenty-year ecosystem to inherit. |
What it shows: CodeRook is built around deciding rather than around integration, and charges for stored bytes rather than for people. What it does not show: nothing here says CodeRook hosts better, is faster, or is safer than any of them. If what you need is the tooling twenty years of adoption built, that is a real reason to stay where you are, and no table changes it.
HORIZONTAL AND VERTICAL
Everyone else is competing sideways. CBX went up.
GitHub, GitLab, Bitbucket, Gitea and Codeberg differ on price, CI minutes, permissions, review tooling and polish. They do not differ on what a repository is. All of them host the same model, so the only way to win among them is to host it slightly better than the one beside you. That is the horizontal axis, and it is crowded.
CodeRook is not on it. CBX moves along a different axis: not who hosts a Git repository best, but how a project’s bytes are represented in the first place — whole snapshots rather than deltas, content-defined chunks below the file boundary, and one lossless path that carries source, weights and media together. Nothing you can do on the horizontal axis moves you along the vertical one. A 40 GB checkpoint is the same problem on every host on that line.
Host the same repository, better
Faster CI, better code search, nicer reviews, more integrations. Real work, and every host on that line is doing it. But moving along it never changes what a repository is, which is why large files have needed a second object store on all of them for fifteen years.
Change what a repository holds
Whole-snapshot Versions, content-defined chunks below the file boundary, tiny-file packs, and one path carrying source and binaries together. This does not make CodeRook a better Git host. It makes the large-content problem stop being yours to work around. The benchmarks below are the units that axis is measured in.
A vertical line that never comes back down is a product nobody can adopt, which is the part most alternatives get wrong. So CBX arcs. git push, git clone and git fetch work against a CodeRook remote. Tags become releases. .gitignore is read exactly as written. Those are doorways in the vocabulary you already have — and what arrives through any of them is still a CodeRook Version, stored the CBX way. Interoperating with Git is not the same as converging on it.
MEASURED, NOT IMPLIED
Benchmarks
The figures below come from the corrected 29–30 August 2026 verification run. Git, Git LFS and Perforce were independently repeated. The Git Xet large-file path was repeated across five fresh content seeds after the first fixed-seed method was found to reuse globally stored chunks. The labels below identify whether a result belongs to CBX alone or to the integrated CodeRook service.
4.26 GiBrestored into an empty folder
→0 file errorsmissing, differing or extra
What this proves: the deployed CodeRook platform running its CBX project-data and transfer technology reconstructed the complete project byte-for-byte. It is an integrated integrity result, not a standalone CBX compression ratio.
768 MiBsource file
+64 KiBregion changed
→1.32 MiBmedian · 0.4–3.1 MiB across seeds
What this proves: a small edit did not make CBX treat the complete 768 MiB file as new. This is calculated chunk content, not an end-to-end network measurement. The median sits on a wide spread — content-defined chunking makes the cost depend on where the edit falls, so the range is quoted beside it rather than left to be assumed.
A local edit can stay local
CBX produced 1.32 MiB median new chunk content for the 64 KiB edit. Default Git represented 768.17 MiB, Git LFS created a 768 MiB object and the Perforce client sent 768 MiB. That is roughly a 582× difference in scale, not a wire-speed ratio.
Stable identities exist below the file
Content-defined chunks give unchanged regions their own identities. A local edit creates new chunks around the changed region while the rest of the file is reused.
Specialized delta paths were smaller
Tuned Git measured about 26 KiB. Git Xet carried a 123 KiB median for the tracked 768 MiB large-file payload. Xet did not replace Git’s commits or version history; this result compares one large-file content path, not two repository models.
768 MiB HIGH-ENTROPY FILE
A localised edit, represented six ways
The workload changed 64 KiB near the middle of one 768 MiB file. These values describe different layers and must not be treated as a network-speed ranking: CBX is calculated new chunk content, Git Xet and Perforce report real transfer, Git reports repository representation, and Git LFS reports large-object payload.
| System | Measured change | What the number means |
|---|---|---|
| CBX content layer · 1 MiB profile | 1.32 MiB median (0.4–3.1 MiB) | Calculated new content-defined chunks across five fresh seeds |
| Git objects · default | 768.17 MiB | The complete high-entropy file was represented again |
| Git objects · delta-enabled | about 26 KiB | Best measured Git result, after non-default large-file tuning |
| Git LFS large-object payload | 768 MiB | A complete new LFS object for the changed file |
| Git Xet large-file payload | 123 KiB median | Xet-carried bytes for a tracked 768 MiB file; Git still recorded the commit and pointer |
| Perforce client RPC | 768 MiB | Full file sent; binary+D kept server archive growth much smaller |
What it proves: CBX avoids the full-file default of Git, Git LFS and the Perforce client for this localised change. What it does not prove: CBX did not produce fewer changed bytes than tuned Git or Git Xet’s large-file transport in this isolated test, and the result says nothing about which repository workflow is better.
512 × 8 KiB FILES
Small edits stay small
One byte changed in one file after the initial Version.
Sixteen files changed after the initial Version.
Deletion-only Version payload, accepted successfully.
This is a CBX result. The 8 KiB files in the Hugging Face test used the ordinary Git/Hub path and xet-core transferred 0 B. Hugging Face’s documented Git workflow tells users to track files larger than 10 MB with Git Xet; smaller files can also be explicitly matched in .gitattributes, but that did not happen in this test. Calling it a CBX-versus-Xet result would be incorrect.
Hugging Face repository guide: Git records commits; Git Xet tracks selected large files ↗
DEPLOYED SERVICE
A CodeRook publish and restore exercising CBX content handling
- Publish v13.77 GiB · 2,021 files · 3.76 GB sent · 31.8 min
- Publish v2500 MiB added plus a 64 KiB edit · 422.2 MB sent in 11 files · 3.6 min
- Clone to empty folder4.26 GiB · 2,032 files · 30.9 min
- Verify0 missing · 0 differing · 0 extra
The changed 1 GiB file was not resent. The complete round trip took about 66 minutes, so the integrity and incremental-transfer result is strong while the roughly 2.1–2.5 MB/s throughput is ordinary. This is an integrated product result: CodeRook supplied accounts, Versions, publication and remote storage; CBX supplied the scan, reusable content plan and exact reconstruction path.
TRADE-OFFS, NOT A SCOREBOARD
What CBX optimizes for—and what it trades
CBX is designed to give CodeRook one dependable project-data path across source code, large binaries and thousands of small files, with complete Versions and byte-exact restoration. It does not optimize one isolated delta measurement at the expense of every other part of that job. These are the boundaries of that choice.
- Specialized paths can produce a smaller isolated delta.Tuned Git represented the 64 KiB fat-file edit in about 26 KiB, while Git Xet’s five-seed large-file median was 123 KiB. Both were smaller than CBX’s 1.32 MiB calculated new chunk content for that payload. This is a narrow byte result: Git required non-default large-file tuning, and Xet handled only the tracked large-file content inside the Git-backed repository.
- Content shape affects chunk reuse.Moving CBX to a 1 MiB target improved the five-seed median 3.3×, but proportional variation widened between seeds. The production profile balances edit reuse against hashing work, object count, request overhead and cross-client consistency rather than chasing the best result from one fixture.
- Changed data still has to be stored.A scattered rewrite across an entire large file can invalidate most chunk identities and approach a complete new payload. Content-defined chunking preserves unchanged regions; it cannot deduplicate bytes that genuinely changed everywhere.
- Portable and live CBX answer different questions.A self-contained
.cbxexport must carry every byte required to restore itself offline. A live CodeRook publication can reuse CBX content already held by the service. Comparing a portable archive with a thin live transfer without naming that boundary would produce a misleading result. - Git has the more mature external ecosystem.CBX has purpose-built CodeRook website, desktop and CLI support, but it does not yet match two decades of Git integrations and third-party tooling. CodeRook keeps a Git compatibility boundary while native CBX tooling grows.
READING THE EVIDENCE
Method and limits
Git and Perforce ran locally on SSD storage. Git Xet used Hugging Face over the public internet, but only for content selected for its Git Xet large-file path; Git still recorded repository commits and pointers. Controlled CBX figures used the production chunker but calculated new chunk bytes without wire framing or server-side dedup. Only the 4 GB CodeRook round trip above was measured end to end against the deployed service. Timings therefore describe their individual runs and are not a fair speed ranking between systems.
Fresh content matters for Git Xet because its global store can make a repeated large-file fixture cost zero bytes. One seed also cannot characterise content-defined chunking: the verified CBX to Git Xet payload ratios ranged from 8.1× to 265.5× before the current CBX profile. The robust finding is the direction, not one dramatic multiplier, and it applies only to the tracked large-file payload.
Why CBX: CBX preserved a byte-exact project restore and reused unchanged content across Versions. In the controlled 768 MiB large-file test, changing 64 KiB created 1.32 MiB median new CBX content instead of treating the complete file as new. That combination of exact restoration and built-in content reuse is why CodeRook uses CBX for project storage and transfer.