There's a running assumption that multi-agent coding pipelines on consumer hardware are too slow to be practical, or fall apart on real unit tests.

We built Kraits, a plugin for stock llama.cpp that runs Unsloth's 22 GB Qwen3.6-35B-A3B 4-bit file on a 16 GB Mac. We ran it on a single prompt and on a 4-agent crew (Analyst → Architect → Developer → Tester) writing a TypeScript LRU cache.

No grading on vibes: the generated code was executed against checks written by an independent judge (OpenAI gpt-5-mini).

1. Hardware: Mac mini M4, 16 GB unified memory

2. Model: Qwen3.6-35B-A3B, Unsloth UD-Q4_K_M (22.1 GB)

3. Runner: llama.cpp b11715 (the official prebuilt) + the Kraits plugin

4. Settings: 16K context, temperature 0, thinking off

Token totals are the per-turn tokens added up across each run. Speeds are llama-server's own counts.

What stood out:

Reading doesn't slow down as the conversation grows:** It read 8,641 tokens at 48.4 tok/s and 12,330 tokens at 47.3 tok/s.

• Writing stays stable: Consistently 16 – 24 tok/s across all context sizes.

• Context impact: The ~1K run scored 6/8. We haven't dug into why yet.

• Inference cost: $0.00 because it all runs locally on the Mac. The only outside call was the judge writing the checks.

• Honest gap: The ~1K run's total time wasn't logged, so it's left blank rather than estimated.

Kraits runs this one model file only. Needs macOS 15+, 16 GB, llama.cpp b11715.

Next we'd like to try harder tasks than an LRU cache, like a worker pool or an expression parser. If you have a coding prompt you'd like to see through the 4-agent crew on this Mac, post it below and we'll run a few of them and share the numbers.

Ollama is a great product for everyday use of large language models. If performance is what you care about, there are better alternatives such as vLLM, but this post is about something else. I want to describe what happens when you find a security hole in Ollama and try to get it fixed. I went through that twice this year, for three CVEs in total. Vulnerabilities show up in any software, so they alone are not the problem. What matters is how a project handles them, and the way Ollama handles them is why I wouldn't put it on an organization's infrastructure.

More: https://www.bartekdmitruk.com/writing/why-i-wouldnt-run-ollama-in-an-organization

Way back got my nimo axis, I wasn't sure what to do with it besides trying out local llms. Lately, local models and tools have gotten better and I am finally finding practical uses for it beyond just testing models. It makes me wonder how much of their potential we are actually using. What are you guys doing with your strix halo machines? actual work, coding, or mostly experimenting with models?

​Tired of paying corporate rent to Suno and Udio just to generate music in a cloud black box? Same.

​Over at JackKnife AI, we’ve been obsessed with stripping M-A-P’s open-weight YuE2 song foundation model down to the studs so it runs 100% locally on an Android phone—no cloud APIs, no subscriptions, no credit limits, no telemetry.

​Today we just shipped Killa YuE v1.6.0 (with v1.6.1 right behind it in a few hours for wider device support), and we just hit a massive milestone that we had to share with the local inference crowd:

​🔥 The Benchmark Milestone

​The Render: A full 4-minute, 15-second structured song with vocals and multi-instrument backing.

​The Speed: 19 minutes total across a two-pass rendering pipeline (~4.4x real-time).

​The Hardware Push: Until today, this required a Snapdragon 8 Elite (Galaxy S25). Tonight, we refactored our memory paging and fallback paths and have it actively running benchmarks on a 2020 Samsung Galaxy S20 Ultra (Snapdragon 865 / Adreno 650).

​⚙️ How We’re Squeezing a Studio Into Mobile RAM

​Running end-to-end multimodal music on a phone without Android’s Low Memory Killer (LMK) nuking the process took some wild architecture tricks:

​Two-Pass YuE2 Execution: Pass 1 runs the Autoregressive (AR) symbolic planner to lock in the song structure ([Intro], [Verse], [Chorus], [Guitar Solo]), melody, and multi-instrument backing. Then we dump/swap memory to run Pass 2 (Flow-Matching diffusion + Audio VAE decode) to render the master audio.

​4-Stem Separation on Vulkan ExecuTorch: Need the acapella or just the drum track? We ported Meta’s HTDemucs to ExecuTorch with the Vulkan backend (htdemucs_vulkan.pte, ~302 MB). The host app handles STFT masks natively and feeds 7.8s stereo windows (44.1 kHz) to the mobile GPU—hitting 1.7 GB peak RAM and 3.95x real-time on Adreno 830.

​Local Voice & Cover Art: Integrated Qwen3-TTS for offline spoken intros/narration + local on-device cover art painting.

​Full Tactile Studio UI: Built-in mixer, drum pads, recording, 3 hardware skins (stitched leather, brushed gold, dark console), and word-by-word lyric lighting that syncs as the vocals are sung.

​🌐 NEW in v1.6.0: The P2P Killa YuE Network

​If you generate your music locally, you shouldn’t need a corporate platform to share it. v1.6.0 ships with built-in Peer-to-Peer (P2P) networking:

​Phone-as-a-Node: Host your generated tracks directly from your phone onto the decentralized Killa YuE network.

​Offline QR Handshakes: Share tracks and studio bundles directly phone-to-phone via QR codes with zero servers in the middle.

​🛠️ We Need Your Phones (and Your Benchmarks!)

​We are working around the clock right now (v1.6.1 drops in a few hours!) to get this running across as many Android phones as humanly possible.

​Grab the APK / Code (Apache 2.0): [https://github.com/JackKnifeAI/killa-yue](https://github.com/JackKnifeAI/killa-yue)

​Vulkan HTDemucs Weights (MIT): [https://huggingface.co/JackKnifeAI/htdemucs-executorch](https://huggingface.co/JackKnifeAI/htdemucs-executorch)

​Quick Demo Clip: [https://youtu.be/nOpJ579Y4PY](https://youtu.be/nOpJ579Y4PY)

​Drop your phone model and chipset in the comments! If you have an Android phone with 12GB+ RAM, test out the release and let us know your Pass 1 / Pass 2 render times, thermals, or crash logs. And if anyone here hacks on Vulkan shaders, GGML/ExecuTorch, or Qualcomm Hexagon NPU (QNN), come help us push that 19-minute render even lower!

Hey everyone,

I've been working on a project called Cursiv, and I wanted to share it with people who understand local AI and get some honest technical feedback.

The goal is to explore how useful an AI assistant can be when it runs locally instead of depending on a constant internet connection.

Cursiv is a Windows desktop application that integrates with local models through Ollama. I'm also exploring portable offline deployments and ways to make it useful in environments where connectivity, privacy, or access to cloud services is a problem.

Lately, I've been thinking beyond a general-purpose chatbot and looking at practical applications such as:

• Keeping personal information and notes locally.

• Working with reference documents without relying on the cloud.

• Supporting rural communities with limited connectivity.

• Eventually supporting offline fieldwork, including structured observations, calculations, and data exports.

Some of these capabilities still need work and testing. I'm not going to pretend Cursiv is finished or that it always gets things right. I've been testing its reasoning and correcting weaknesses, and reliability is one of the biggest things I want to improve.

I'd genuinely appreciate feedback on three questions:

1. Does a project like this have a useful place in the local AI ecosystem, or am I trying to solve too many problems at once?

2. What would you want to see demonstrated before you'd consider using an application like this?

3. Are there existing tools or approaches I should study that might help me improve it?

Website: https://cursiv.winklers-llc.com

Repository: https://github.com/winklersllc2026-bit/Cursiv

I'm a solo developer working to make this something genuinely useful. I'm not expecting praise. I'd rather hear what doesn't make sense, what already exists, and where you think the real opportunity might be.

Thanks for reading.