mohsen1/yek: a Rust CLI that packs a repository into one file for LLM context

The problem yek solves: one flat file instead of a directory tree

Feeding a codebase to a language model usually means concatenating files by hand, or writing a shell loop that forgets .gitignore, includes lockfiles and produces an order nobody can explain. Yek exists to replace that loop. The README describes it as a fast Rust based tool to serialize text-based files in a repository or directory for LLM consumption, and the default behavior is deliberately opinionated: it uses .gitignore rules to skip unwanted files, uses Git history to infer which files matter more, and infers additional ignore patterns for binaries and large files.

The target user is an engineer who wants a single text artifact they can paste into a chat window, pipe to a clipboard, or hand to an agent. Yek is not a retrieval system and not a code index. It produces one file, or one stream, and the README states that the path to that file is printed to the console. The name is Farsi for one, which matches the output: one file out of many.

How the serialization pipeline orders and filters files

The mechanism visible in the README and Cargo.toml is a walk, a filter and a sort. The dependency list includes ignore, glob, walkdir, git2, rayon, crossbeam, tiktoken-rs and content_inspector, which maps to the described behavior: walk the input paths, apply ignore rules, inspect content to detect binaries, count tokens when asked, and parallelize the work.

The ordering rule is the part worth understanding. Yek prioritizes more important files to come last in the output, and the README explains why: LLMs tend to pay more attention to content that appears later in the context. Importance is inferred from Git history, which means a file touched often in recent commits tends to land near the end. That is a heuristic, not a ranking you control directly, and the README does not document the exact scoring formula. What you can control is the config file, which the README says can define file priority rules for processing order and configure Git-based priority boost.

Output formatting is a template. The default is a header line with the file path followed by the file content, and the CLI exposes --output-template with FILE_PATH and FILE_CONTENT placeholders. A tree header can be prepended with -t, or the tree alone can be printed with --tree-only.

Installing yek and running a first serialization

The README gives a one-line installer for Unix-like systems and a PowerShell equivalent for Windows. The script is fetched from azimi.me and piped into a shell, so read it first if your environment treats remote scripts as untrusted.

curl -fsSL https://azimi.me/yek.sh | bash

On Windows the README documents this form:

irm https://azimi.me/yek.ps1 | iex

Building from source is also documented, and the repository has a Cargo.toml at the root, so the toolchain route works without the installer:

git clone https://github.com/mohsen1/yek
cd yek
cargo install --path .

Once installed, running yek with no arguments in a repository serializes the whole thing and writes to a temporary file, printing the path. If you want the content on stdout instead, pipe it. The README shows the clipboard case on macOS:

yek src/ | pbcopy

The README notes that yek detects when output is being piped and streams content instead of writing to files, which is why the pipe form behaves differently from a bare invocation. For a bounded context window, cap the output by tokens:

yek --tokens 128k

The README states that yek removes files that will not fit in the capped context size and tries to fit in more important files first. Before you paste anything into a hosted model, run the tree-only mode to see exactly which files were selected:

yek --tree-only

Where yek is the wrong tool

Yek is a serializer, so it inherits the limits of one flat text blob. There is no chunking strategy, no embedding step and no retrieval at query time. If your repository exceeds the model context even after --tokens trims it, yek will drop files rather than summarize or split them into a searchable index. The README is explicit that files which do not fit are removed, and the same README does not document rollback or a way to see what was dropped beyond --debug output.

The ordering heuristic is the second limitation. Git history is a proxy for importance, and it fails in specific situations: a freshly cloned repository with shallow history, a vendored directory that is committed rarely, or a generated file that changes on every build. In those cases the last file in the output may not be the file you care about. The config file is the escape hatch, since it accepts file priority rules and a Git-based priority boost setting, but the README does not spell out the full schema for either, so expect to read the repository's yek.yaml for the actual keys.

Finally, the ignore rules are the safety boundary. Yek respects .gitignore and adds built-in patterns for binaries and large files, and --unignore-patterns exists to override those built-ins. Anything that is tracked by Git and looks like text will be serialized, including secrets committed by mistake. Yek does not scan for credentials.

How yek differs from Repomix and Gitingest

The closest comparisons people search for are Repomix and Gitingest, and the difference is in scope rather than speed. Those tools also pack a repository into a single artifact for model consumption, and they typically add their own output formats and integrations. Yek's distinguishing choices are narrower: it streams to stdout when piped, it caps output by bytes or by tokens with tiktoken-rs, and it orders files so the important ones come last rather than first. The README frames that ordering as a deliberate response to how models weight later context.

If you need a packaged report with a fixed structure, or an editor extension, yek is not that. If you need a binary you can drop into a Makefile or a shell pipeline and control with flags, yek is closer to the shape you want. The repository also ships benches with criterion and a bench.toml, so performance claims are backed by a benchmark harness rather than a marketing page, though the README's performance section is where any numbers would live.

Configuration, maintenance and the MIT licence

Yek reads a yek.yaml at the project root, and the repository itself contains one. The README lists what the file can hold: additional ignore patterns, file priority rules, extra binary extensions, Git-based priority boost, output directory and filename, and output template. Most CLI options have a config equivalent, including max_size, tokens, ignore_patterns, unignore_patterns, json and debug. Two flags bypass the file entirely: --no-config skips loading any configuration, and --config-file points at a specific path.

Maintenance signals are concrete. The repository is not archived, and the last push was on 2026-06-29, with v0.25.5 released the same day. Releases in the v0.25 line arrived on 2026-06-02, 2026-06-06 and 2026-06-29, so the cadence in that window was weeks apart. The Makefile encodes the release path: make release runs test and lint before scripts/make-release.sh, and the lint target runs cargo clippy with -D warnings plus cargo fmt --check. That means a released binary passed clippy and formatting checks in CI, not just tests.

The licence is MIT, declared in both Cargo.toml and the LICENSE file at the repository root. MIT permits commercial use and modification with attribution and no warranty. The vendored-openssl feature on git2 is worth noting if you build from source, because it compiles OpenSSL rather than linking the system copy, which affects build time and binary size. That is a build characteristic, not a legal one; for licence questions about your own distribution, talk to someone qualified.

Editorial conclusion

Adopt yek if you already pipe file contents into a model and want deterministic ordering, a token cap and .gitignore respect from a single binary. Skip it if you need structured chunking, retrieval or a service, because yek produces one flat text artifact. Before trusting it on a private repository, run yek --tree-only and yek --debug on that repository and read the file list, since the built-in binary and large-file ignores are the only thing standing between your working tree and the output.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mohsen1/yek on GitHub
4. README
5. Releases