praseodym

zstd has a built-in benchmark mode to compare different compression levels, e.g. `zstd -b1 -e9 [FILE]` to test levels 1 to 9 (try up to 22 if you have enough spare time)

Note that the dictionary options are only needed to improve compression ratios when compressing lots of small messages. If you have a bigger file (eg a tar file of Usenet messages) the regular Zstd compression will build a good dictionary without additional options.

This also adds a lot of moving parts and failure modes. For self-hosting I’d rather have downtime on a simple system that’s easy to fix rather than a complex setup that stays up but needs more maintenance when some component fails.

My home server is an ASUS NUC 14 Essential which idles at 5W with a bunch of services running. Its peak performance is probably less than the Mac Mini, but the hardware is cheap (at least it was before RAM/storage got expensive) and it’s a great platform to run Linux on.

Claude Code also doesn't make it easy to make _efficient_ use of the different models to reduce overall cost. There are many tokenmaxxing features (e.g. ultracode that spawns dozens of subagents) to burn through the 5-hour limit in minutes, but if you want to let an Opus planning agent use Sonnet for implementing you have to orchestrate your own workflow. I'm pretty sure that's because the Anthropic employees working on Claude Code have unlimited token budgets so they're mostly on tokenmaxxing workflows themselves.

As mentioned by others it’s just as easy for an attacker to modify a crate’s runtime code.