FAQ
Short answers, with the page that owns each one.
Is deleting the cache safe?
Always. The store is a cache of work mbx can redo: the worst case is a colder build, never a wrong one. See stability.
Why wasn't my first build faster?
A first build has an empty store — there is nothing to hit, so it can only cost time, and the summary's "could not look up" line dominates. Time the second build instead. See cache results and the cold scenario in benchmarks.
Why does a fully warm build still take time?
Links mbx cannot describe always run — a large binary re-links even when every compilation hit. Host binaries and tests are restored on Linux, macOS, and Windows, and self-contained WebAssembly targets everywhere; the rest is limits.
The cache stopped hitting after a Rust update. Is it broken?
No — the compiler is part of every key, so a toolchain roll invalidates every rustc action at once, and the build says so: a manifest predicting N compilations was loaded, but none matched this build. The benchmarks cover this in the toolchain scenario. Actions that do not depend on rustc, such as a build script's C objects, legitimately survive.
Can I use mbx together with sccache?
No. Both wrap rustc through RUSTC_WRAPPER, so they cannot be combined for the same build; with RUSTC_WRAPPER already set, mbx defers to it and does not cache. See migrate from rust-cache or sccache.
Are restored artifacts byte-identical to what a compile would produce?
Equivalent, not always identical: rustc and C compilers record absolute source paths in metadata and debug information, so artifacts from two checkouts can differ without behaving differently. MBX_VERIFY=1 compares bytes and names what differed. See limits.
Where does everything live?
mbx cache dir prints the store's location. Managed target directories live under the same root (managed targets), and configuration comes from the paths listed at the top of configuration.
How do I turn one feature off?
Every feature has its own switch:
| Switch | Turns off |
|---|---|
MBX_SCHEDULER=0 | machine-wide compile scheduling |
MBX_CC=0 | build-script and mbx exec C and C++ caching |
MBX_TARGET_VIEWS=0 | managed target directories |
MBX_CACHE_LINKS=0 | native link caching |
MBX_LEARNED_INCREMENTAL=0 | learned incremental reuse |
MBX_EVENTS=0 | per-compilation event streams |
MBX_SAVINGS=off | the savings line |
Something looks wrong. What should a report include?
mbx doctor --json, a run with MBX_LOG=debug, and MBX_BYPASS_LOG. See reporting a problem.
Why is it called Mr. Boxington?
The project is named after this cardboard box, christened “Mr. Boxington” by jdx's daughter while he was working on mbx. The name stuck.
For non-English speakers
The joke is in “Boxington”: it combines box with -ington, an ending familiar from English place names and surnames. The result makes an ordinary cardboard box sound like a distinguished gentleman.
The original Mr. Boxington.