# Experiment in reducing target directory size on nightly

DevFeed: [Experiment in reducing target directory size on nightly](<https://devfeed.tech/articles/experiment-in-reducing-target-directory-size-on-nightly-15102.md>)

Original publisher: [Read original article](<https://blog.rust-lang.org/inside-rust/2026/08/18/reducing-target-dir-size-on-nightly/>)

Author: Jakub Beránek

Published: 2026-08-18T00:00:00Z

Content type: article

Language: en

Sources: [Inside Rust Blog](<https://devfeed.tech/sources/inside-rust-blog.md>)

Topics: [Rust](<https://devfeed.tech/topics/rust.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [data](<https://devfeed.tech/topics/data.md>)

Tags: [compilation](<https://devfeed.tech/tags/compilation.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [disk-space](<https://devfeed.tech/tags/disk-space.md>), [information](<https://devfeed.tech/tags/information.md>), [rust](<https://devfeed.tech/tags/rust.md>), [space](<https://devfeed.tech/tags/space.md>), [state](<https://devfeed.tech/tags/state.md>)

## AI overview

The Cargo Team is testing -Zembed-metadata=no by enabling it by default on the nightly channel. The experiment aims to reduce Rust target directory size by avoiding duplicated crate metadata in build artifacts, while gathering feedback about viability and user impact.

## Source excerpt

TL;DR: The Cargo Team will be rolling out an experiment to identify user impact for a proposed change. Cargo will enable the -Zembed-metadata=no feature on the nightly channel by default, which can help reduce the size of the target directory somewhat. This is an experiment designed to gather feedback about viability of this feature. Users are not expected to migrate to support this feature, but to report any issues and opt-out if needed in the meantime. What is this about? High disk usage of Rust compilation artifacts is frequently cited as one of the biggest annoyances of Rust users. In our 2025 State of Rust survey, it was actually the second most commonly reported problem, right after compilation speed. There are various reasons why the target directory can become quite large, such as: Cargo compiles the whole crate graph from scratch by default, which produces a lot of build artifacts. Debug information takes a lot of disk space. Incremental compilation artifacts take a lot of disk space. While you can disable debug information or incremental compilation to reduce the target directory size, that of course comes with severe trade-offs in compilation speed and debuggability of your program. However, there is one source of data in the target directory that currently takes too much size even though it doesn't really have to. It is the "crate metadata", which can be duplicated across multiple files. We will focus on that in this blog post. What causes duplicated (meta)data For years, Cargo has been using pipelined compilation to speed up building of crate graphs. When compiling a library crate, it tells the compiler to produce an .rmeta file (which contains all the crate metadata required to use this library) as soon as possible, even before having the final executable code available. This enables dependent crates to start compiling sooner. However, once the library does finish compiling, the final produced .rlib file will contain both the executable code and the Ru