Native compiler · Linux x86-64 · C++20 / C11

The compiler that does the repeated work for you.

AIR is a general-purpose native compiler designed to be useful to coding agents. Write compact, typed, effect-checked source. Get verified IR, structured diagnostics and a native executable, with no garbage collector and no Python runtime in the result.

One language and runtime · three connected platforms · compiler-owned project knowledge
hello.ai
module hello

pub fn main(args: view<str>) -> i32
    effects {io.write} {
  io.write("Hello from AIR\n")
  0
}
terminal
$ airc run hello.ai --mode release
Hello from AIR
$ airc build hello.ai -o hello --json
{ "kind": "build-report",
  "provenance": { "compiler": "airc", ... },
  "unit": { "sources": [ ... digests ... ] } }
157standard library modules
382verified IR operations
24native applications in-tree
6native model families
0GC pauses · interpreter runtimes
Why AIR

Stop maintaining facts the compiler already knows.

“What work am I repeatedly doing that the compiler could do for me?”

Most engineering time is not spent writing new logic. It goes into keeping codecs, bindings, build graphs, schemas and documentation in sync with declarations that already exist. AIR's advantage comes from taking that work off the author. Syntax serves that purpose, not the other way around.

The result is measured across the whole job: understanding a codebase, finding dependencies, making a change, diagnosing a failure, and maintaining it afterwards.

  • Derived, not duplicatedCodecs come from record fields, runtime operations bind from one declaration, and intermediate products are managed for you.
  • Explicit where it mattersTypes, ownership, borrowed views, affine handles and declared effects are visible in every signature.
  • Verified before it runsEvery program passes an IR verifier with stable instruction IDs before code generation.
  • Native by defaultC11 through the system compiler gives a native binary: no GC, no interpreter, nothing extra to ship.
  • Built for agent-assisted developmentStructured JSON diagnostics, exact repairs and live capability queries replace guesswork.
Architecture

From compact source to a verified native binary.

One pipeline, with a reference interpreter beside it for checking. Every stage is inspectable, and canonical IR can be exported with full source provenance.

Source.ai

Compact, typed modules with declared effects

LoweringAIR IR

Explicit instructions with stable IDs

CheckingVerifier

Types, ownership, effects, borrows

OptimizeOptimizer

Verified transformations

EmitC11

Portable, readable output

DeliverNative binary

GCC or Clang, no runtime to install

Platform 1

General application platform

Ordinary native applications with the libraries needed to build them.

  • Collections, files, processes, time
  • HTTP clients & servers, TLS transport
  • Durable indexed storage & SQLite
  • Tasks, telemetry, GUI, media
Stdlib + native GTK desktop toolkit
Platform 2

AI development & agent platform

Compiler-owned project knowledge that agents query instead of reconstructing it.

  • airproj projects, locks & impact analysis
  • Exact repairs & verification receipts
  • std.agent deterministic policy
  • Live capability & schema queries
Deterministic knowledge first, model reasoning second
Platform 3

Native AI & model platform

GPU provider and model libraries that run inference pipelines inside native AIR programs.

  • Affine device, memory & stream resources
  • BF16/FP8/INT8 tensors & quantization
  • Pinned block offloading & residency budgets
  • H3, Krea 2, Qwen-Image, Z-Image & more
One language and runtime, not separate products
The language

Explicit semantics. Minimal ceremony.

AIR keeps the facts reviewers need in the signature and removes the plumbing nobody should write by hand.

Every side effect is declared.

Functions list what they touch: allocation, filesystem, network, GPU, time. The compiler rejects a call that needs an effect its caller hasn't declared, so capabilities can be audited from signatures alone.

Reviewers and agents can see at a glance that a formatting helper cannot open a socket.

report.ai
fn summarize(path: str) -> result<string, fs.error>
    effects {alloc, fs.read} {
  let body: string = try files.read_text(path)
  result.ok(text.concat("bytes: ",
    string.from_int(str.len(body))))
}

// Drop fs.read from the signature and the build stops:
// error AIR-E0402 [summarize]: callee 'std.files.read_text'
//   declares effects {fs.read} that summarize does not

Owned values, borrowed views, affine handles.

Strings and arrays are owned; str and view<T> borrow without copying. GPU buffers, files and task handles are affine resources that must be closed exactly once. The compiler enforces it, with no runtime tracing.

ownership.ai
fn longest(items: ref<array<string>>) -> u64 effects {} {
  var best: u64 = 0
  var i: u64 = 0
  loop {
    if i == array.len(items) { break }
    let item: str = str.view(array.borrow(items, i))  // borrow, no copy
    if str.len(item) > str.len(str.view(array.borrow(items, best))) { best = i }
    i = i + 1
  }
  best          // no allocation, no effects declared
}

Declare the record. Get the codec.

derive codec(strict) generates checked JSON encoding and decoding from the record fields: no hand-written serializer to drift from the type, and no generated source files. Strict records reject unknown and duplicate members with a precise path. Generic records, enums and functions specialize into concrete AIR with the same ownership and effect checks.

task.ai
pub type Task = struct {
  id: u64, title: string, done: bool, tags: array<string>
} derive codec(strict)

// AIR generates Task_decode and Task_encode. No generated files.
match Task_decode(body) {
  ok(value) => { var task: Task = value
                 reply = try Task_encode(task) },
  err(problem) => report(problem),   // e.g. unknown_field at /extra
}

Structured concurrency, typed channels.

task.spawn must appear inside a task.scope, and the compiler rejects any handle that tries to leave it. Tasks receive owned arguments and return one owned result, with nothing shared implicitly. GUI applications stay responsive while heavy GPU work runs in owned tasks.

fanout.ai
task.scope {
  var jobs: array<task<u64>> = array.new()
  var i: u64 = 1
  loop {
    if i > 4 { break }
    array.push(jobs, task.spawn(i, fn=square))
    i = i + 1
  }
  loop {
    match tasks.join_next<u64>(jobs, tasks.forever()) {
      some(result) => { total = total + result },
      none => { break },
    }
  }
}   // handles can never escape the scope that spawned them
For coding agents

Deterministic compiler knowledge gets the first word.

The compiler owns semantic truth. AIR's native std.agent policy decides what to do with it. The language model reasons only once AIR has no current proof, so it never has to guess at what the compiler already knows.

Ask the compiler, not the model

Live, conservative answers derived from the compiler's schema and standard-library declarations, with exact signatures, effects and source identities.

airc capability "Does AIR provide SHA-256?" --json
airc schema --library std.json --json
airc project context app.ai --name report_digest --json

Persistent knowledge, never stale

Build the structural and semantic map once and keep it updated incrementally, so the model doesn't have to rediscover the codebase every session. Every stored answer carries its authority identity and requires a fresh query before use, so a stale result is blocked instead of trusted.

  • Answers are available, unknown, or unavailable only with complete authority
  • Exact, machine-applicable repairs routed through verification
  • Atomic receipts and crash-recovery state for bounded workers
CapabilityAIRTypical toolchain + LLM
Source of API truthLive compiler schemaModel memory, docs that drift
DiagnosticsStructured JSON with stable IDsFree-form text to parse
RepairsExact, verified before applyingModel-generated guesses
Side-effect auditDeclared in every signatureRead the whole call graph
Project knowledgeIncremental, authority-checkedRe-derived every session
Native AI

Real generative models, running as native AIR programs.

AIR's GPU provider and model libraries run whole inference pipelines in-process: checkpoint loading, pinned block offloading, INT8 attention, VAE decode and media muxing. Nothing hands off to Python. Each model's documentation states its actual admission level.

Model familyWhat runs nativelyStatus
MiniMax H3Text / keyframe / reference-to-video with synchronized audio; ConvRot INT8 projections, CK dense INT8 attention, pinned bounded residencyShipping in MM-Air
Krea 2 TurboQwen3-VL conditioning, 28-block denoising, 8-step Turbo schedule, any-size tiled VAE decode (512–2048 px)Complete generator
Qwen-Image 2.1Text-to-image and 1–10 source editing, pinned residency with zero checkpoint reads per stepGenerate & edit
Z-Image TurboNative text-to-image through the same compute and loading infrastructureIntegrated
YuE2Native tokenizer, 28-layer AR/NAR, midpoint solve, Oobleck decode to waveformIntake in progress
LTX-2Model intake on the shared compute libraryIntake in progress

Provider-neutral compute

Linear, activation, normalization, modulation, RoPE and grouped-query attention behind a small C ABI. The first provider targets NVIDIA via the CUDA Driver API, NVRTC and cuBLASLt.

Memory that fits the card

Pinned host slabs, two-slot block offloading and largest-first device residency budgets let large models run on 24 GB GPUs without re-reading the disk every step.

Opt-in by design

GPU applications bundle the provider through an application-relative RUNPATH. Ordinary AIR programs neither require nor link it.

Genesis AIR editor: media bin, source and program monitors, properties dock and a multi-track timeline
Flagship application

Genesis AIR: a non-linear video editor, written in AIR.

A real editor, not a showcase. It has source and program monitors, a multi-track timeline with transitions, fades, markers and waveforms, keyframed properties, scopes and an audio mixer, plus MP4 export through a separate media worker.

51filter kinds (31 video, 20 audio)
~8klines of AIR, with no edit arithmetic of its own
1place a project fact lives: the document
0lines of AIR copied in, only an SDK pin
user input  →  editor command  →  project state changes  →  UI redraw

Split, trim, ripple, slip, roll, slide, undo/redo, transitions and keyframes all come from AIR's reusable NLE toolkit (std.editor), which was itself derived from Genesis. The application only decides what a click means.

Built with AIR

Proven on real applications.

AIR is developed against the software built with it. Friction found in these applications gets fixed in the compiler and libraries.

Genesis AIRNon-linear video editor: timeline, monitors, 51 filters, MP4 export
MM-AirNative H3 filmmaker workspace: generate, edit, movie, prompt lab
AIR LensPhoto & video browser with editing and in-preview playback
WorkbenchBuild/test runner with dependent tasks, checkpoints and history
TaskboardWork-item CLI + HTTP service with durable restart
AIR DiskLargest files, duplicates and scan diffs, in GUI + JSON CLI
AIR ChatDesktop chatbot with streaming replies and SQLite history
air-agentBounded, model-neutral worker with verification receipts
Get started

From clone to native binary in minutes.

Requires CMake 3.25+, Ninja, and GCC 13+ or Clang 16+ with C++20/C11 support. Python 3 is used only for tests. Supported host: Linux x86-64.

What you get

  • airc: compile, run, verify, export canonical IR
  • airproj: projects, dependencies, locks, capabilities
  • A tested pattern index with expected results
  • Sanitizer build presets for the compiler and runtime
Configure and build

Use the development preset.

cmake --preset dev
cmake --build --preset dev -j 4
Run the test suite

Everything is checked with CTest.

ctest --test-dir build-dev --output-on-failure -j 4
Write and run a program

run verifies, builds, executes and cleans up.

build-dev/bin/airc run hello.ai --mode release
Ship a binary

Keep the executable, with a JSON report of every source digest.

build-dev/bin/airc build hello.ai -o hello --mode release --json
FAQ

Common questions

Is AIR a scripting language?

No. AIR compiles to C11 and then to a native executable through the system compiler. There is no garbage collector, no interpreter, and no Python runtime in generated programs. A reference interpreter exists for checking the compiler, not for running applications.

Do I need a GPU to use AIR?

No. The GPU provider is optional and opt-in. Ordinary applications (CLIs, services, desktop apps) never link it.

What does "designed for coding agents" mean in practice?

Agents get the same authoritative answers the compiler uses: structured diagnostics, live capability and schema queries, project context, exact repairs and verification receipts. The model is released to reason only where the compiler has no current proof.

What platforms are supported?

The supported host today is Linux x86-64. The implementation is C++20/C11, built with CMake and Ninja using GCC 13+ or Clang 16+.

How are claims about model support verified?

Each model family's documentation records its admission level: which gates passed, with hashes, measured results and what remains open. AIR doesn't claim parity it hasn't measured.

Let the compiler carry the load.

Typed, verified and native, with compiler knowledge available to every agent.