HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
jundot
omlx
Python2026–2026
jundot / omlx

omlx

LLM inference server with continuous batching & SSD caching for Apple Silicon — managed from the macOS menu bar

9Distinct people
15Mentions
0Explicit recommenders
23.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

LLM inference server with continuous batching & SSD caching for Apple Silicon — managed from the macOS menu bar

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by week15 dated mentions

Observed mentions: 2026-02-13 17:18:43 UTC to 2026-06-29 18:10:43 UTC. Weeks start Monday, UTC.

0122026-02-09 00:00:00 UTC to 2026-02-16 00:00:00 UTC (exclusive): 2 mentions; 2 submissions, 0 commentsFeb 92026-02-16 00:00:00 UTC to 2026-02-23 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2026-02-23 00:00:00 UTC to 2026-03-02 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2026-03-02 00:00:00 UTC to 2026-03-09 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2026-03-09 00:00:00 UTC to 2026-03-16 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-03-16 00:00:00 UTC to 2026-03-23 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-03-23 00:00:00 UTC to 2026-03-30 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-03-30 00:00:00 UTC to 2026-04-06 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-04-06 00:00:00 UTC to 2026-04-13 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-13 00:00:00 UTC to 2026-04-20 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-04-20 00:00:00 UTC to 2026-04-27 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsApr 202026-04-27 00:00:00 UTC to 2026-05-04 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2026-05-04 00:00:00 UTC to 2026-05-11 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-05-11 00:00:00 UTC to 2026-05-18 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2026-05-18 00:00:00 UTC to 2026-05-25 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2026-05-25 00:00:00 UTC to 2026-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-01 00:00:00 UTC to 2026-06-08 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-08 00:00:00 UTC to 2026-06-15 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-06-15 00:00:00 UTC to 2026-06-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-22 00:00:00 UTC to 2026-06-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-29 00:00:00 UTC to 2026-07-06 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJun 29

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Feb 92026-02-09 00:00:00 UTC2026-02-16 00:00:00 UTC220
Feb 162026-02-16 00:00:00 UTC2026-02-23 00:00:00 UTC110
Feb 232026-02-23 00:00:00 UTC2026-03-02 00:00:00 UTC110
Mar 22026-03-02 00:00:00 UTC2026-03-09 00:00:00 UTC211
Mar 92026-03-09 00:00:00 UTC2026-03-16 00:00:00 UTC000
Mar 162026-03-16 00:00:00 UTC2026-03-23 00:00:00 UTC000
Mar 232026-03-23 00:00:00 UTC2026-03-30 00:00:00 UTC000
Mar 302026-03-30 00:00:00 UTC2026-04-06 00:00:00 UTC101
Apr 62026-04-06 00:00:00 UTC2026-04-13 00:00:00 UTC000
Apr 132026-04-13 00:00:00 UTC2026-04-20 00:00:00 UTC101
Apr 202026-04-20 00:00:00 UTC2026-04-27 00:00:00 UTC101
Apr 272026-04-27 00:00:00 UTC2026-05-04 00:00:00 UTC202
May 42026-05-04 00:00:00 UTC2026-05-11 00:00:00 UTC000
May 112026-05-11 00:00:00 UTC2026-05-18 00:00:00 UTC110
May 182026-05-18 00:00:00 UTC2026-05-25 00:00:00 UTC110
May 252026-05-25 00:00:00 UTC2026-06-01 00:00:00 UTC000
Jun 12026-06-01 00:00:00 UTC2026-06-08 00:00:00 UTC000
Jun 82026-06-08 00:00:00 UTC2026-06-15 00:00:00 UTC101
Jun 152026-06-15 00:00:00 UTC2026-06-22 00:00:00 UTC000
Jun 222026-06-22 00:00:00 UTC2026-06-29 00:00:00 UTC000
Jun 292026-06-29 00:00:00 UTC2026-07-06 00:00:00 UTC101

What Hacker News says

15 sources
I've been working with local models for the past year. There's so many possibilities, but I don't think coding is one. Coding requires so many layers beyond inference; I spent so much time trying to replicate what Claude Code does end to end locally. Understanding all the layers and keeping up with the advancements feels like a slog. Even this article messes up and misunderstands what some of the settings are doing. Qwen in particular seems to work at first, then often gets stuck in thought loops when used for actual work. However, text-to-speech, speech-to-text, and non-code LLM use cases are so useful to have local, and don't require big hardware. Having a universal reliable inference engine interface, I think, is the big unlock that needs to happen before app devs can ship these features. Personal concrete use case: meeting recording a
Read the rest
pp. This uses Parakeet + Qwen to create local transcriptions and post-cleanup, respectively. Right now this app has to download and manage all these models, then bundle an inference engine to run them. It's a lot of code that probably should belong to the OS, or at least a standard interface. While apps can offload some of this to llama.cpp or a similar process over http, that's another set of setup for the user to do before they can have a useful app. Anyway, if you're getting started on a Mac, I'd suggest trying out oMLX (https://github.com/jundot/omlx) before messing with llama.cpp. In particular they have community benchmarks so you can see what kind of performance you're likely to get: https://omlx.ai/benchmarks. I wished each one had more configuration details though.
In Qwen 3.6 27B is the sweet spot for local development
Hi HN, I'm the developer. I built oMLX because every Mac LLM server I tried fell apart with coding agents. The core problem: tools like Claude Code and OpenClaw send requests where the prompt prefix keeps shifting. Most servers invalidate the KV cache after each turn, forcing a full re-prefill. On large contexts (50-100K tokens), that means 30-90 seconds of waiting per request. After a few turns, it's practically unusable. oMLX solves this with paged SSD caching. Every KV cache block is persisted to disk. When a previous prefix comes back, it's restored from SSD instead of being recomputed. In practice, TTFT drops from 30-90s to 1-3s on follow-up requests. Cache blocks survive server restarts too. What's under the hood: - Continuous batching via mlx-lm (multiple concurrent requests) - Multi-model serving (LLM + VLM + Embedding + Reranker
Read the rest
simultaneously, LRU eviction) - OpenAI + Anthropic compatible APIs Tool calling support(JSON, Qwen, Gemma, MiniMax, GLM formats + MCP) - Native macOS menubar app (PyObjC, signed DMG) — download, drag, done As of v0.2.0: Vision-Language Model support with the same tiered caching Benchmarks on M3 Ultra 512GB with Qwen3-Coder-Next-8bit: 58.7 tok/s single request, 243 tok/s at 8x batch. Full results on the README. It reuses LM Studio's model directory, so you don't need to re-download anything. 100% open source (Apache 2.0): https://github.com/jundot/omlx
In Show HN: oMLX – SSD-backed KV cache cuts coding agent TTFT from 90s to 1s on Mac
jundot·Feb 24, 2026Submission

Show HN: oMLX – coding agents on local LLMs without the painful reprefill

I was frustrated that coding agents like Claude Code were basically unusable with local models. every few turns the prefix shifts, KV cache gets invalidated, and your mac has to re-prefill the entire context from scratch. So i built oMLX. it persists KV cache blocks to SSD, and when a previous context comes back, it restores from disk instead of recomputing. this alone made Qwen3-Coder-80B on my M3 Ultra actually usable for real coding sessions. Some other stuff it does: continuous batching, multi-model serving (LLM + embedding + reranker at once), prefix sharing with copy-on-write, and a native mac menubar app so you don't have to touch the terminal. Just shipped a built-in benchmark tool too, so you can test your own setup easily.
3 points · Open discussion
jundot·Feb 19, 2026Submission

Show HN: oMLX – Native Mac inference server that persists KV cache to SSD

I built an open-source LLM inference server optimized for Apple Silicon. The main motivation was coding agents - tools like Claude Code send requests where the context prefix keeps shifting, invalidating KV cache. A few turns later the agent circles back, and your Mac has to re-prefill the entire context from scratch. oMLX solves this with paged SSD caching. Every KV cache block is persisted to disk. When a previous prefix returns, it's restored instantly instead of being recomputed. This makes long coding sessions significantly faster. It also supports continuous batching for concurrent requests, multi-model serving (LLM + embedding + reranker) with LRU eviction, block-level KV cache with prefix sharing and copy-on-write, OpenAI and Anthropic compatible APIs, and tool calling. Ships as a signed macOS menubar app with a web dashboard. Git
Read the rest
1 points · Open discussion

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.