# Rust build insights {#rust-build-insights} Build Insights helps you find what slows your Cargo builds down and catch regressions before they affect the whole team. You can compare local builds with CI, see how build times change, and inspect the crates compiled in each build. > [!IMPORTANT] > **Requirements** > > - Follow the <.localized_link href="/guides/get-started/rust-project">Rust project setup to connect your project and authenticate. ## Report your builds {#report-your-builds} Run your usual Cargo commands through Tuist: ```sh tuist cargo build --workspace tuist cargo check --all-targets tuist cargo +nightly build --features tracing ``` If you use mise, <.localized_link href="/guides/get-started/rust-project#keep-typing-cargo">configure a Cargo wrapper to keep using ordinary `cargo` commands. Your arguments, toolchain selection, output, and exit code stay the same. ## Find what slows a build down {#explore-your-builds} Open a build from **Builds → Build Runs** on the dashboard. Use the date, environment, and Rust-version filters to compare similar builds. Builds and their cache counters are also available through `tuist build cargo list` and `tuist build cargo show`, `GET /api/projects/{account_handle}/{project_handle}/cargo/builds`, and the `list_cargo_builds` and `get_cargo_build` <.localized_link href="/guides/features/agentic-coding/mcp">MCP tools. On **Overview**, use **Compiler jobs** to find slow crates. Sort by **Duration** or **Started after** (time since the Cargo command started), or search by crate name or root source file. Each row is one `rustc` invocation for a crate, which can contain many source files. **Crate root** identifies its root source file; the duration is for the whole compiler job, not that file alone. A crate can appear more than once for different targets or configurations. Compiler messages are grouped in **Warnings** and **Errors**. ### Track crates across builds {#crate-history} When available for your project, **Builds → Crates** shows observed crates and their compilation history. Open a crate to compare its recorded durations and outcomes across builds, then follow a compilation back to its Cargo build. The same inventory is available through `/cargo/crates` in the project API and the shared MCP build-entity tools with `kind: cargo_crates`. Crates are grouped by their exact recorded root path, name and kind. Changing checkout paths can split histories; profiles, features and target triples are not distinguished. This is an inventory of observed compiler jobs, not every crate in your workspace. Cached or up-to-date crates do not create compilation samples. ### Attribute build reports {#report-attribution} Authenticated reports identify the individual behind personal credentials. Shared credentials need not identify an individual. Optionally set `TUIST_ACTOR_ID` to a stable opaque identifier on the reporting machine; it is off by default and is displayed as an unverified claim, never used for authorization. Older servers may ignore the claim. Do not put secrets in it. ## Read the timings {#timing-boundaries} The build duration is how long the whole Cargo command took. Compiler jobs can run in parallel, so their durations won't add up to the build duration. Cargo only compiles crates that need rebuilding. Crates that are already up to date won't appear in the compiler list. With Tuist's compilation cache, restored jobs appear in the cache measurements, not as compiler executions. Tuist doesn't measure build scripts separately or show a build Timeline. A large build shows the first 500 compiler jobs, with a notice if more were recorded. ## Read cache measurements {#cache-measurements} `tuist cargo` includes an experimental compilation cache implemented in the Tuist CLI. Follow the <.localized_link href="/guides/features/cache/rust">Rust cache guide for setup, remote reads and writes through Kura, supported compilations, and troubleshooting. Open **Cargo Cache** in the project sidebar to track cache hit rates and recorded transfer, latency, and throughput measurements across builds. Filter by date or environment, switch between daily trends and individual-build hit rates, or open a recent build to inspect its cache activity. Builds without cache measurements remain unavailable rather than counting as zero. Open a build's **Cache** tab to see task hits, task misses, hit rate, and downloaded and uploaded bytes. The tab appears when the build reports cache data. - **Cacheable Tasks** shows which compiler and build-script tasks reused cached outputs. Search or filter the tasks, inspect cache read/write latency, and expand a row to see its outputs. - **CAS Outputs** shows artifact downloads and uploads, with their sizes, durations, and throughput. The chart counts completed transfers; already-present artifacts and failed attempts remain in the table. **Hit** means cached outputs were reused. **Missed** means the task compiled instead. Hits aren't split into local and remote; CAS Outputs shows the recorded artifact operations. If detailed records are missing or incomplete, the page shows a notice. The summary still covers the whole build. Estimated compiler work avoided is **not elapsed build time saved**. > [!WARNING] > **Experimental compilation cache** > > The cache is experimental and qualified on Apple silicon Macs. Libraries are cached by the sources the compiler read, on every platform, but library caching on Linux isn't qualified yet. Build scripts, procedural macros, executables and native code are cached only on Apple silicon Macs. Cache keys replace checkout and toolchain paths with placeholders, so reuse works for checkouts at different paths on the same machine, not across machines. Incremental compilations build normally. ### Builds that run tests {#builds-that-run-tests} `tuist cargo test` reports the duration of the whole command, including its tests. It also reports individual test outcomes, including doctests, through <.localized_link href="/guides/features/test-insights/rust">Rust Test Insights. Individual test results appear under **Tests**; the command duration appears in build insights. ## Other compiler tools {#other-compiler-tools} Tuist preserves existing compiler wrappers configured through `RUSTC_WRAPPER`, `CARGO_BUILD_RUSTC_WRAPPER`, or Cargo configuration, and leaves `RUSTC_WORKSPACE_WRAPPER` intact. A pre-existing global wrapper disables Tuist's cache and compiler observer: Tuist cannot establish whether that wrapper actually ran rustc. Custom workspace wrappers can likewise leave fewer compiler jobs in the report. Tuist finds Cargo through rustup. If you use a custom installation, set `TUIST_CARGO_EXECUTABLE` to its executable path. Calling Cargo by a direct toolchain path bypasses mise's wrapper. A Cargo alias can't replace a built-in command such as `build`. If you use Cargo's nightly `-C` option, change into the workspace first instead: Tuist forwards `-C` commands but doesn't collect their build timings. ## Troubleshooting {#troubleshooting} If a build doesn't appear in the dashboard, enable debug output to see why its report wasn't sent: ```sh TUIST_DEBUG=1 tuist cargo build --workspace ``` Reporting doesn't change the result of your build.