Proposal: Explore a Rust Port of Kimi CLI — Offering Hands-On Help

Proposal: Explore a Rust Port of Kimi CLI — Offering Hands-On Help

Disclaimer up front: I know how this sounds. "Rewrite it in Rust" is usually the kind of issue maintainers eye-roll and close immediately. I’m opening this anyway because I’ve personally done exactly this kind of migration, it worked far better than I expected, and I’m offering to do a meaningful chunk of the work—not just drop an idea and walk away. I’m also genuinely open to being told I’m missing something here.

My personal experience: Java → Rust, zero regrets

I recently completed a personal migration of a production codebase from Java to Rust. The result: zero issues, production-ready, and I’m significantly happier with the maintenance burden. The software just works.

The code quality isn’t perfect—but that’s not because the AI couldn’t write good Rust. It’s because I rushed to ship features rather than clean up generated code. The key insight: refactoring is no longer a blocker. With AI agents, restructuring code or even porting to another language becomes "ask a few agents in parallel and review the output" rather than weeks of manual work.

Why I started questioning Python for a CLI

To be blunt: I found installing the Python-based CLI less convenient than I expected. pip install or pipx install works, but compared to dropping a single binary in ~/.local/bin, it feels like unnecessary friction. That got me thinking: why does a CLI tool need a Python runtime at all?

I initially thought Rust might struggle with TUI libraries or ecosystem maturity for this kind of tool. I was wrong. The Rust TUI ecosystem (ratatui, crossterm, etc.) is robust and actively maintained. I also expected the library landscape to feel niche or incomplete — it doesn’t. It’s surprisingly mature for the kinds of things a CLI needs (HTTP clients, config parsing, async I/O, JSON/TOML/YAML, etc.).

Go would also be a solid choice here, and I wouldn’t argue against it. I’m specifically wondering about Python because, for a self-contained CLI, the traditional reasons for Python (huge ecosystem, fast iteration) matter less when AI is doing the iteration, and the runtime costs (startup time, distribution, packaging) remain.

Why this is becoming normal (not crazy)

Noah Mitchem’s recent article If AI Writes Your Code, Why Use Python? captures the shift well. A few highlights:

• Microsoft rewrote the TypeScript compiler in Go for ~10x speedup because the effort calculus changed under them.
• Nicholas Carlini (Anthropic) orchestrated 16 parallel Claude agents to write a production C compiler in Rust — 100,000 lines, boots Linux on x86/ARM/RISC-V, compiles QEMU/SQLite/Redis, total cost ~$20,000.
• Andreas Kling ported Ladybird’s JS engine from C++ to Rust in two weeks with AI assistance — 25,000 lines, byte-for-byte parity, zero regressions across 65,000+ tests.
• Astral (ruff, uv, ty) went from zero to hundreds of millions of monthly downloads, all Rust. OpenAI acquired Astral noting that uv saves Codex ~1 million minutes of compute per week.
• Bun — itself a high-performance JavaScript runtime — has been actively moving core components from Zig to Rust, which suggests even projects born in "fast" languages see value in Rust’s tooling and ecosystem for AI-assisted development.

The common thread: the constraint that made high-performance languages expensive (human slowness at low-level code) is disappearing. AI agents excel at languages with tight compile-check feedback loops—and Rust’s compiler is essentially a free training signal for models.

Why specifically a CLI tool?

A CLI is arguably the best candidate for this kind of port:

1. Single binary distribution — no Python runtime, no pip install, no virtualenv headaches, no "which python" issues. Users download one file and run it.
2. Startup time — CLI tools are invoked repeatedly; Rust’s near-zero startup latency matters.
3. Cross-platform builds — cargo build --target beats wrestling with Python packaging for Windows/macOS/Linux.
4. Small footprint — a Rust binary is megabytes; a Python CLI drags in a runtime measured in tens to hundreds of megabytes.
5. The Python "ecosystem" argument matters less — a CLI is a relatively self-contained program. It doesn’t need PyTorch or Django.

What I’m offering (concretely)

I’m not asking the maintainers to commit to a rewrite. I’m offering to:

• Build a proof-of-concept port of core CLI functionality (argument parsing, config loading, basic API calls) in Rust.
• Run it alongside the Python CLI so you can A/B test without risk.
• Help gradually migrate modules if the experiment proves worthwhile.
• Document the process so the community can follow along.

I can dedicate real time to this because AI-assisted Rust development is genuinely fast and pleasant. The hard parts (borrowing, lifetimes, async) are exactly what agents handle well.

Suggested approach (if there’s interest)

Rather than a big-bang rewrite, I’d suggest:

1. Spike: Port the command dispatcher + config layer to Rust as a standalone binary.
2. Validate: Test it against real usage patterns, measure startup time and binary size.
3. Iterate: If results are promising, port feature-by-feature behind a kimi-rs feature flag or separate install channel.
4. Decide: Either gradually cut over or keep both implementations with the Rust version as the preferred native install.

Bottom line — and I’m open to being wrong

I understand this is a big ask for a project that already works. My claim is simply that the cost of trying is now much lower than it used to be, and the potential upside (faster startup, easier distribution, smaller footprint, arguably easier maintenance with AI assistance) is worth a small experiment.

But maybe I’m missing something. If there’s a compelling reason Python is the right long-term choice for Kimi CLI — something beyond "it’s already written in Python" — I genuinely want to hear it. I’m not trying to attack the current stack; I’m trying to understand whether the ground has shifted enough that a different stack makes more sense going forward.

If the maintainers are even mildly curious, I’ll start the spike and report back with real numbers. If not, I totally understand—feel free to close this issue and I won’t be offended. 🙂

---

Reference: If AI Writes Your Code, Why Use Python? — Noah Mitchem

Start by reviewing the existing Python CLI's command dispatcher and config layer, then define a standalone Rust proof of concept covering those entry points and basic API calls. Validate it against real usage patterns and compare startup time and binary size before deciding whether further migration is warranted.