The open-source AI coding stack, layer by layer

You can assemble almost the whole coding-agent stack from open source today. Downloadable model families, agent loops whose source you can read end to end, harnesses built to be extended rather than forked — the lower layers are crowded with options. What the crowded layer charts never show is the top of the stack: the coordination layers that decide which work runs, remember what happened, and prove the result. There, open source thins out fast, and that thinning is the most useful fact a stack map can carry.

This page is that map. What a coding-agent harness is draws the boundaries between layers precisely; here the question is the assembly itself — at each layer, what it contributes, which open-source projects occupy it, and where YYLO's components sit when the layer is otherwise empty. Six layers, six decisions, every named project checked against its public page on 2026-08-28.

Six layers, six decisions

• Model — which weights do the reasoning, and what license covers them. The cheapest layer to swap and the easiest to misjudge, because "open" splits into two documents here.
• Agent — which loop turns reasoning into repository changes. The tool-using loop is the thing you are actually choosing whenever someone says "coding agent".
• Harness — what hosts the loop. Where sessions live, how configuration is expressed, which tools are bound, and what you can extend without forking.
• Control plane — what decides and bounds the work. Dispatch, isolation, quotas, review, and admission: the discipline above any single session.
• Task truth — where the durable record lives. Intent, status, responses, dependencies, and commit links: memory that outlives every session.
• Evaluation — how the stack proves itself. Repeated attempts, retained evidence, and governed grading on real repositories.

The boundary guide counts five layers because it folds the top three into a single control plane and adds the IDE as a serving surface for humans. Assembling a stack forces the split back apart: orchestration, memory, and measurement get chosen separately. YYLO's control plane drives agents it did not author, the Ledger keeps truth for workflows that never invoke the Benchmark, and the Benchmark grades runs the control plane dispatched, whichever agent executed them. Three components, three decisions, each separable from the others.

The model layer: open weights, two licenses

The reasoning layer has genuinely open inventory. DeepSeek-V3 presents "DeepSeek-V3, a strong Mixture-of-Experts (MoE) language model with 671B total parameters with 37B activated for each token", and the family runs on your own hardware through Ollama, whose one-line pitch is a roll call of downloadable families: "Get up and running with Kimi-K2.6, GLM-5.2, MiniMax, DeepSeek, gpt-oss, Qwen, Gemma and other models". When one box is not enough, vLLM is "A high-throughput and memory-efficient inference and serving engine for LLMs" under Apache-2.0.

The precision this layer demands: "open source" here means two licenses, not one. DeepSeek-V3's README states the split explicitly — "This code repository is licensed under the MIT License", while "The use of DeepSeek-V3 Base/Chat models is subject to the Model License", a separate document under which the series "supports commercial use". An MIT code license does not cover the weights the code serves, and some family repositories — Qwen3's, on the evidence date — display no license identifier at all. Read the model license before shipping anything built on the weights; that reading is this layer's real cost of entry.

In a composed stack the model stays a per-run selection — -m on the next invocation — rather than a product identity, and that is what keeps the layer swappable. What swapping is worth to you is the portability audit's question, not this map's.

The agent layer: loops you can read

The agent layer is the tool-using loop itself: it exposes repository tools to the model, executes the model's decisions, and loops the results back in. The open-source options span the styles:

• OpenCode — MIT; the repository's entire self-description is "The open source coding agent."
• Aider — Apache-2.0; "aider is AI pair programming in your terminal".
• Codex CLI — Apache-2.0; "Lightweight coding agent that runs in your terminal".
• Gemini CLI — Apache-2.0; "An open-source AI agent that brings the power of Gemini directly into your terminal".

One boundary worth holding: an open-source agent is not yet an open-source stack. The license covers the loop; the reasoning usually still happens behind an API you pay for. The stack becomes open end to end only when the loop points at weights you serve yourself. The loop also matters less than the layers above it, because from the control plane every loop is a service invocation — YYLO documents first-party services including claude, codex, gemini, pi, and cursor, and any further loop can be wired in as a custom service script under ~/.yylo/services/. How several such loops share one workflow — steps, handoffs, a single admission gate — has its own guide.

The harness layer: the container the loop ships in

In open source, agent and harness almost always arrive as one repository. Pi is the tidiest illustration: a single MIT project describing itself as an "AI agent toolkit: unified LLM API, agent loop, TUI, coding agent CLI" — model access, the loop, a terminal interface, and a complete coding agent in one package. The harness is the container half of that package: session storage you can re-enter, configuration that lives as files, an extension surface that replaces forking, and an unattended mode for CI runs that no human ever watches.

When you assemble a stack, the harness question is which bundle to live in, and the seam matters for two reasons. The harness decides what persists between invocations — sessions you can reopen and branch — and what stays yours when the agent moves on, because configuration expressed as reviewable files travels with the repository. The precise boundary between loop and container, with worked examples, belongs to the harness guide; this map only records that the layer is well supplied, since every agent project above ships its own.

The control plane: the layer open source keeps forgetting

Above the harness, the questions change shape. Which work is worth a run at all? How much runs concurrently, and where does each run execute so parallel agents cannot overwrite one another? What bounds a run, what evidence must it leave behind, and who admits the result into shared history? Dispatch, isolation, quotas, gates, and integration — answering those is the control plane's job.

It is also the emptiest shelf in the open-source stack. Public tooling crowds around weights and loops; the coordination layer's value is discipline and durable records, which demo poorly and matter daily. Teams that notice the gap usually fill it with a proprietary platform — or with nothing, meaning cron jobs and hope. YYLO exists to fill it as part of an open stack instead: the README's opening sentence is that "YYLO orchestrates AI coding agents and structured development workflows", the documentation introduces the product as "the open-source control plane for agentic engineering work", and the source is public on GitHub.

One check this map exists to make: on the evidence date, GitHub listed an MIT license on the Ledger and Benchmark repositories but no license at all on the CLI repository. Verify in the repository itself before redistributing the control plane — the same two-document discipline the model layer taught, applied to YYLO.

Task truth: the memory layer

Sessions record what was said inside one conversation. Task truth records what happened to the work: the intent behind a change, its status, the responses agents produced, dependencies between units, and the commits that landed them. The default open-source answer is a Markdown TODO file in the repository — perfectly good for one author keeping a list — and it goes no further: dependency-aware readiness, evidence-grade responses, and immutable history are exactly what a flat file does not hold, so teams that need them usually rent a hosted tracker.

The open alternative built for agents is YYLO Ledger. The repository carries an MIT license and the self-description "Git-native task, workflow, receipt, and archive ledger"; the documentation calls it "The Git-native, dependency-aware source of truth for task intent, status, blockers, responses, history, archives, and commit evidence" — all of it inside your repository rather than behind an account. The introductory treatment of the Ledger as durable agent memory has its own guide.

Evaluation: the proof layer

The top layer answers the one question the other five cannot: does this stack actually work, on your repository, repeatedly? Public benchmark suites cover the shared version of that question. SWE-bench, MIT-licensed, asks "Can Language Models Resolve Real-world Github Issues?" against real issue threads; Terminal-Bench, Apache-2.0, is "A benchmark for LLMs on complicated tasks in the terminal". Instruments like those are comparable across systems by design — and finished once the run ends.

What a shared instrument cannot hold is longitudinal evidence for your repository and your change types. That half of the layer is a component you run: YYLO Benchmark, MIT-licensed, with the repository's own one-line identity "longitudinal evaluation and immutable evidence for agent runs" and a documentation contract that sums up as "Validate immutable plans, execute isolated attempts, govern grading, reconcile evidence, and produce bounded reports". Runs leave receipts rather than only scores, which is what keeps the evidence auditable after the fact.

Where the components fit, and what to verify

Read as a map: the model and agent layers offer real choice, the harness layer is rich but bundled, and the top three layers are where open source runs out — which is exactly where YYLO's three components sit. The CLI orchestrates, the Ledger remembers, the Benchmark proves, and the README states the working relationship in one sentence: "YYLO orchestrates AI coding agents and structured development workflows. It works alongside YYLO Ledger, the Git-native task and workflow ledger, and YYLO Benchmark, the longitudinal evaluation and evidence system for agent runs."

If you are evaluating that claim, evaluate it where it lives. The next-step panel below links all three repositories, and reading them is the cheapest due diligence this stack offers: the Ledger's task schema, the runner scripts the control plane installs, and the Benchmark's receipt contracts are ordinary files in public repositories, and the two evidence components carry MIT licenses. A repository visit tells you what any map goes stale on — which parts move fast, which parts are boring on purpose, and whether the licenses still say what this page recorded.

Every project named here was checked against its linked public page on 2026-08-28 — descriptions and licenses quoted from those pages, absences included — and every YYLO claim against its committed documentation and READMEs. Licenses, descriptions, and model families move; re-verify before you rely on them. Two neighboring questions have deeper owners: the portability audit if what you are weighing is exit cost rather than assembly, and the harness boundary guide when the seam between loop and container needs precision rather than a map.