this looks cool for game development, because using Git for projects in Unity and Unreal Engine definitely has it's issues. I'm personally not a fan of Git LFS, especially since GitHub charges you to use it (which makes sense, binaries and assets are big, code is small, relatively speaking).
Exactly this, and this tool called qmd is what I use for the hybrid search portion. It also uses local LLMs to provide summaries on your own markdown data too. My agents use both depending on what type of search they are doing, and both provide good results.
So Opus 4.7 is measurably worse at long-context retrieval compared to Opus 4.6. Opus 4.6 scores 91.9% and Opus 4.7 scores 59.2%. At least they're transparent about the model degradation. They traded long-context retrieval for better software engineering and math scores.
Did you also try Forgejo? If so, what are the differences between the two? I didn't even know GitLab had a self-hosted option. I assume it's probably better for Enterprise-grade projects, and dealing with CI/CD, actions, etc. But for smaller projects that just have issues and PRs and minor test suites, I assume Forgejo is the better lightweight option.
I have enjoyed using Forgejo over GitHub for local work. The features that GitHub has that plain Git does not includes a nice web renderer of markdown and code, issues and pull requests with comments, and project kanban boards. It's nice to have an alternative for local usage if GitHub ever goes down or just for private projects. Especially nice with agentic workflows, because agents can port issues, PRs, etc. back and forth between GitHub and Forgejo.
Coqui TTS is actually deprecated, the company shut down. I have a voice assistant that is using gpt-5.4 and opus 4.6 using the subsidized plans from Codex and Claude Code, and it uses STT and TTS from mlx-audio for those portions to be locally hosted: https://github.com/Blaizzy/mlx-audio
Here are the following models I found work well:
- Qwen ASR and TTS are really good. Qwen ASR is faster than OpenAI Whisper on Apple Silicon from my tests. And the TTS model has voice cloning support so you can give it any voice you want. Qwen ASR is my default.
- Chatterbox Turbo also does voice cloning TTS and is more efficient to run than Qwen TTS. Chatterbox Turbo is my default.
- Kitten TTS is good as a small model, better than Kokoro
- Soprano TTS is surprisingly really good for a small model, but it has glitches that prevent it from being my default
But overall the mlx-audio library makes it really easy to try different models and see which ones I like.
If you want your comments to sound more human — stop using em dashes everywhere. LLMs love them — along with neat structure, “furthermore”-style transitions, and perfectly balanced paragraphs.
Humans write a bit messier — commas, short sentences, abrupt turns.
The RTX 5090 only has 32gb of VRAM. So the tradeoff is NVIDIA is for blazing speed in a tiny memory pool, but Apple Silicon has a larger memory pool at moderate speed.
I'm running a local voice agent on a Mac Mini M4. Qwen ASR for STT and Qwen TTS on Apple Silicon via MLX, Claude for the LLM. No API costs besides the Claude subscription but the interesting part is the LLM is agentic because it's using Claude Code. It reads and writes files, spawns background agents, controls devices, all through voice.
The insights about VAD and streaming pipelines in this thread are exactly what I'm looking at for v2. Moving to a WebSocket streaming pipeline with proper voice activity detection would close the latency gap significantly, even with local models.
Do you think it would be possible in the future to maybe add developer settings to enable or disable certain features, or to switch to other sandboxing methods that are more lightweight like Apple seatbelt for example?
OpenAI Codex CLI was able to use it effectively, so at least AI knows how to use it. Still, its deprecated and not maintained, Apple needs to make something new soon.
Yup it uses Apple Virtualization framework for virtualization. It makes it so I can't use the Claude Cowork within my VMs and that's when I found out it was running a VM, because it caused a nested VM error. All it does is limit functionality, add extra space and cause lag. A better sandbox environment would be Apple seatbelt, which is what OpenAI uses, but even that isn't perfect: https://news.ycombinator.com/item?id=44283454
I've been running something similar for a few months, which is a voice-first interface for Claude Code running on a local Flask server. Instead of texting from my phone, I just talk to it. It spawns agents in tmux sessions, manages context with handoff notes between sessions, and has a card display for visual output.
The remote control feature is cool but the real unlock for me was voice. Typing on a phone is a terrible interface for coding conversations. Speaking is surprisingly natural for things like "check the test output" or "what did that agent do while I was away."
The tmux crowd in this thread is right that SSH + tmux gets you 90% of the way there. But adding voice on top changes the interaction model. You stop treating it like a terminal and start treating it like a collaborator.
The friction didn't disappear with AI tools. It just shifted. It's now more so about knowing when to trust an AI system versus when to dig into things yourself. The key insight is this: don't devalue learning things on your own. AI is a tool, but if the tool messes up, you need other tools in your toolbox. If you've only ever leaned on the AI, you're in trouble the moment it fails on something subtle.
If you give an LLM enough context, it writes in your voice. But it requires using an intelligent model, and very thoughtful context development. Most people don't do this because it requires effort, and one could argue maybe even more effort than just writing the damn thing yourself. It's like trying to teach a human, or anyone, how to talk like you: very hard because it requires at worst your entire life story.
Pro tip: if you pay for Claude, also subscribe to status updates here: https://status.claude.com . you may want to add a rule to filter these to a tag or folder as they can be quite spammy, but it has helped me lots. It tells you which specific models are down and what platforms are down, such as claude web, app, API, etc.
Heads up: Whisper support depends on how your FFmpeg was built. Some packages will not include it yet. Check with `ffmpeg -buildconf` or `ffmpeg -filters | grep whisper`. If you compile yourself, remember to pass `--enable-whisper` and give the filter a real model path.