In development

Elix Apple-Native Agentic AI Runtime

The full on-device AI stack for the Mac - a declarative pipeline DSL, a shared service that manages resources across apps, and an MLX-based inference engine tuned for Liquid Foundation Models.

  • Composable pipelines
  • Shared service
  • Inference engine
  • On-device

The Elix Stack

Three components, one runtime. Apps describe what they want at the top - everything below is Elix's job.

Your app's request
  1. Composable Pipelines

    1

    Describe your intent in a simple, declarative way - a Swift-first DSL where you compose models, adapters, guardrails, and tools like SwiftUI, and the compiler lowers it into a parallelized execution graph.

  2. Shared Service

    2

    Every app talks to one shared service over XPC. It manages resources across clients, executes requests, and offloads the LLM when inactive - an idle assistant costs the user zero RAM.

  3. Inference Engine

    3

    Best-in-class inference performance for Liquid Foundation Models - MLX-based and tuned per chip, with custom Metal kernels, speculative decoding, and quantization.

Apple silicon

Composable Pipelines

Our vision for how agents should be built: define AI pipelines the way you write SwiftUI - declarative, native Swift. You describe intent; the compiler handles orchestration.

A toolchain, not a prompt library

Prompting a model directly is the assembly era of AI - you talk to the processor in its raw instruction set. It works, and it doesn't scale: hand-tuned prompt chains are hard to maintain, tied to one model's quirks, and optimized by hand, one target at a time. Software solved this decades ago.

Software
Source code AST Compiler Runtime CPU
Elix
Pipeline DSL Codable AST Compiler Walker Any model

Composable Pipelines is that same structure, built for AI. The DSL declares intent; everything below the declaration - dependency analysis, parallel scheduling, incremental re-execution, each model's dialect - is the toolchain's job, not yours.

  • The program is an artifact

    A pipeline lowers to a Codable AST - encode it in your app, decode it in the service, print it back as readable pseudo-Swift. The graph is the wire format, not a byproduct.

  • Scheduled like a CPU

    The compiler orders steps by data hazards - read-after-write, write-after-write - the way instruction schedulers do, then emits deterministic parallel batches.

  • Models are compile targets

    Chat templates, tool-call formats, and capability-based model selection live below the DSL. Swap the model like you'd retarget a build - the pipeline doesn't change.

Each step reads the slot the previous one wrote - a straight data-dependency chain.

struct DocumentSummaryPipeline: Pipeline {
    typealias Output = String
    let document: String

    @State var keyPoints = ""
    @State var draft = ""
    @State var summary = ""

    var body: some Pipeline {
        Model<String>("Extract the 5 key points.").message(document).assign(to: $keyPoints)
        Model<String>("Summarize from these points.").input { $keyPoints }.assign(to: $draft)
        Group { Summarize(text: $draft, maxTokens: 512).assign(to: $summary) }
    }
}
Execution-tested examples from the open-source repo - browse the full sources
  • Intent, not infrastructure

    Swift structs with @State and native control flow, composing Model, Guardrail, ForEach, and ClientTask - no YAML, no wiring.

  • Parallel by construction

    The compiler analyses @State reads and writes and batches independent branches automatically - concurrency for free.

  • Compile once, run anywhere

    The Codable graph runs in-process on iOS, across XPC on macOS, or in a test simulator - same pipeline, every target.

Open source - Apache 2.0

The pipeline layer is open

Composable Pipelines - the authoring, IR, and compiler layer of Elix - is open source under Apache 2.0. Swift 6.1+, on macOS 14+, iOS 17+, and Linux, with an OpenAI-compatible executor in the box so pipelines run against Ollama or mlx-lm today.

.package(url: "https://github.com/MacPaw/ComposablePipelines", from: "0.1.0")

Elix as a Shared Service

We value our users' resources: instead of every app running its own LLM instance and consuming memory independently, one shared service serves them all - a good citizen on macOS.

Many clients, one service

App 1App 2EneyApp 4App 5
Shared Service One background process - requests from every client batched, caches shared, and one queue scheduled fairly:
  • Guardrail checks preempt
  • Every app gets its turn
  • Crashed clients reclaimed
One LLM in memory A single resident model serves everyone - loaded on demand, offloaded when clients go inactive.

The memory math

Every app runs its own LLM 15 GB
3 GB3 GB3 GB3 GB3 GB
One shared LLM through Elix 3 GB −80% RAM
3 GB

Five apps share one 3 GB model instead of loading five copies - and when every client goes idle, the service offloads the model entirely: 0 GB.

The privacy boundary

Private by construction, not by policy - the service never opens files, holds secrets, or calls your APIs. Every side effect runs in a ClientTask on the client, same shape on macOS and iOS.

// Pipelines declare intent; ClientTasks own the outside world.
ClientTask(
    input: query,
    action: { encodedQuery in
        // Runs in the client process - full access to
        // keychain, entitlements, UI, file system, network.
        let token  = try Keychain.read("calendar-api-token")
        let result = try await CalendarAPI(token: token).search(encodedQuery)
        return try JSONEncoder().encode(result)
    }
)
  • Everything stays on your Mac

    Prompts, completions, files & secrets, inference itself - there is no network path from inference. It works with Wi-Fi off.

  • Telemetry - counts, not content

    Only counts and durations leave the machine, over pinned TLS - never your text.

  • Models are the only download

    Offline-first and SHA-256-verified - the one network hop in the system.

  • Only signed clients are served

    Every client is signed and validated before the service talks to it.

Purpose-Built Inference Engine

The layer that runs the models. Built on MLX, rebuilt where it counts - and measured against stock on every chip we ship.

How it's built

  • From scratch

    Built directly on MLX, Apple's array framework for the Mac - unified memory, Metal-backed kernels, and pure Swift. Native from the metal up, no Python runtime.

  • Quality over quantity

    Supporting few models is the advantage: each one gets full attention - custom Metal kernels, tuned quantization, and every optimization that matters for latency and throughput.

  • Tuned per chip

    Every Apple silicon generation gets its own fastest configuration - chosen by measurement on real Macs, not extrapolated from one machine.

What that buys you

  • Instant first token

    Prefill tuning and model cache reuse cut time-to-first-token, so output starts the moment the user hits enter.

  • Native-speed streaming

    Metal kernels and speculative decoding push tokens-per-second past stock runtimes - smooth even on a laptop.

  • No network tax

    Everything runs on the Mac - no round-trips, no rate limits, no cold starts waiting on a remote server.

Optimizations across the stack

Cross-cutting techniques adopted throughout Elix - every layer moves through the same build, measure, ship loop.

Measured - Elix engine vs. stock mlx-lm
Stock mlx-lm +10% +20% +30%
M4 Pro 161.4 → 177.5 tok/s +10%
M3 Ultra 237.2 → 293.4 tok/s +24%
M3 Max 169.2 → 190.1 tok/s +12%
M2 Pro 111.1 → 119.3 tok/s +7%
M2 66 → 69.9 tok/s +6%

Decode throughput, LFM2.5 models at 4-bit - median tok/s averaged over 128–16k-token contexts, each chip vs. its own baseline. Measured without speculative decoding and with identical model weights for a fair side-by-side comparison. Last updated in August 2026.

  • Pure Swift No Python between tokens
  • Metal kernels Custom GPU kernels for Apple silicon
  • Speculative decoding Faster generation, identical output
  • Quantization 4-bit weights and caches, near-full quality
  • MoE optimization Efficient expert dispatch on Apple GPUs
  • LoRA adapters Merged and retrieved on demand
  • Cache reuse Model caches persist across turns
  • Per-chip tuning The fastest configuration for each Mac

Powered by Liquid AI

Elix runs fully on Liquid Foundation Models created specifically for it - developed in the joint R&D of the MacPaw and Liquid AI technological partnership.

  • Created specifically for Elix

    Not off-the-shelf checkpoints: joint R&D shapes the models for the tasks Mac products actually ship.

  • Optimized for the engine

    Efficient by architecture, then quantized and tuned for Elix's kernels on Apple silicon.

  • Co-developed, shipped together

    Models, inference, and memory designed as shared infrastructure - Eney is the first product on the stack.

Visit Liquid AI

Beyond text generation

LFM is more than chat models. Liquid AI ships compact encoder task models - single-pass classifiers, taggers, routers, and retrievers at 350M parameters - and Elix runs them the same way it runs generation: as steps in a pipeline.

Multilingual PII detection

Spots 40 kinds of personal data across 16 languages and redacts them in one bidirectional pass - no generation loop, nothing leaves the Mac.

LiquidAI/LFM2.5-Encoder-350M-PII-Detector
Input text

Reschedule my 3pm call with John Smith and text him at +1 234 567 890. Then pay the studio invoice with card 4111 1111 1111 1111 and email the receipt to [email protected] from [email protected].

Detected
  • Identity 1
  • Contact 3
  • Financial 1

What you can build with Elix

The runtime is agentic and shared by design - these are the patterns it serves first.

Build with Elix

Elix is in development. Working on a Mac product that needs on-device intelligence? Join the waitlist for early access - or talk to us about partnership.

Join the Waitlist