Why
Downstream projects are starting to depend on parakeet.cpp and running into a distribution wall. The current reality is: to use the `parakeet` binary, users must clone, build axiom + parakeet.cpp from source, handle Apple's Xcode-vs-CLT shader-compiler gotcha (axiom's Metal kernel compile needs `metallib`, which ships only with full Xcode, not Command Line Tools), and get cmake happy. That's a real adoption cliff.
Two concrete data points from the last week:
What would move the needle
In rough order of value:
- GitHub releases with prebuilt binaries. Even just macOS arm64 + macOS x86_64 + linux x86_64 static-ish archives of `parakeet` would unblock the majority of downstream consumers. CI can attach them on tag. Happy to PR a `.github/workflows/release.yml` if you'd accept it.
- Homebrew formula (either `homebrew/core` or a tap). Follows naturally from (1).
- Docs note about Xcode vs CLT on macOS source builds. One-line cost, saves real user time.
Why (1) matters beyond convenience
Our `examples/server` warm-daemon pattern from #19 is the exact shape downstream projects want for per-request reuse, but none of that helps Minutes users who can't even get the binary installed. Any investment in the warm-daemon or library-level improvements (e.g. the LM cache in #20) is gated on the binary being reachable. Releases unlock all of it.
What I'm not asking for
Full Homebrew core upstreaming on day one, CI for every platform, or signed/notarized builds. Just something better than source-only distribution as the default.
Happy to do the work on (1) if you want the PR. Flag how you'd want it structured (workflow file location, asset naming, static vs dynamic, etc.) and I'll send it.
Why
Downstream projects are starting to depend on parakeet.cpp and running into a distribution wall. The current reality is: to use the `parakeet` binary, users must clone, build axiom + parakeet.cpp from source, handle Apple's Xcode-vs-CLT shader-compiler gotcha (axiom's Metal kernel compile needs `metallib`, which ships only with full Xcode, not Command Line Tools), and get cmake happy. That's a real adoption cliff.
Two concrete data points from the last week:
minutes setup --parakeetand document Xcode-vs-CLT build cliff silverstein/minutes#162.What would move the needle
In rough order of value:
Why (1) matters beyond convenience
Our `examples/server` warm-daemon pattern from #19 is the exact shape downstream projects want for per-request reuse, but none of that helps Minutes users who can't even get the binary installed. Any investment in the warm-daemon or library-level improvements (e.g. the LM cache in #20) is gated on the binary being reachable. Releases unlock all of it.
What I'm not asking for
Full Homebrew core upstreaming on day one, CI for every platform, or signed/notarized builds. Just something better than source-only distribution as the default.
Happy to do the work on (1) if you want the PR. Flag how you'd want it structured (workflow file location, asset naming, static vs dynamic, etc.) and I'll send it.