{"slug": "open-sourcing-eraser-diagrams", "title": "Open-Sourcing Eraser Diagrams", "summary": "Eraser Labs has open-sourced Eraser Diagrams, an AI-native, coordinate-aware diagram format released under the MIT license, with the spec, reference renderer, and examples available on GitHub. The company argues that frontier models became fluent at coordinate-based layout in late 2025/early 2026, making deterministic layout engines like ELK unnecessary and enabling models to control layout directly, which allows for instructions like 'make it fit on a slide' that Mermaid cannot express.", "body_md": "[← Eraser Diagrams](/open-source)\n\n# Open-sourcing Eraser Diagrams\n\nLLMs outgrew Mermaid. So we built what comes next.\n\n*Eraser Diagrams is an AI-native, coordinate-aware diagram format, open-sourced under the MIT license. The spec, a reference renderer, and a gallery of examples are live at [github.com/eraserlabs/eraser-diagrams](https://github.com/eraserlabs/eraser-diagrams). This post is about why it needs to exist.*\n\n## What changed\n\nUntil recently, LLMs could not be trusted with layout.\n\nMore precisely: they were poor at translating design intent into coordinates. Ask a model to place shapes on a canvas and you’d get overlapping nodes, orphaned labels, spaghetti lines. This is why AI diagram generators – Eraser included – have always relied on deterministic layout engines like ELK. The model decided *what connects to what*; the engine decided *where everything goes*. That division of labor was the only way to guarantee legible output.\n\nThen, in late 2025 / early 2026, it stopped being necessary. Frontier models became genuinely fluent at coordinate-based layout.\n\nWhich means the model can now be asked for much more than hierarchy and direction. It can be asked for the layout itself.\n\n## “Make it fit on a slide”\n\nTo give layout engines their due: they’re great for small, simple diagrams. They assume a strong primary direction and then optimize, mostly to minimize line crossings. For a ten-node flowchart there are only so many ways to lay things out, and the engine usually finds a good one.\n\nBut past a certain size and complexity, minimizing crossings starts working *against* what a diagram is actually for: telling a story, in reasonable dimensions.\n\nWe knew we’d hit a wall when one of our most common user prompts – “make this diagram fit on a slide” – was frustratingly inexpressible in our own pipeline. When the model can only say “A connects to B” and the engine owns every coordinate, that request has nowhere to go, so it gets ignored. Same for “put the databases on the right column,” “span the monitoring group across the entire bottom,” and every other instruction about *where*. With older models, this was a cost we accepted. But the latest models dissolve this problem: we can let them say where things go.\n\n## Why diagrams matter\n\nA fair question: in an age where AI agents do most of the execution work anyway, aren’t ASCII diagrams and Mermaid good enough? Do we need anything better?\n\nFor the agents – no. An agent is roughly indifferent to whether information arrives as a wall of text, a diagram, or binary. But humans process visual information far more efficiently than text, and humans are the ones who have to keep up. The ultimate bottleneck of the AI era won’t be getting agents to generate work; it will be the human capacity to process, evaluate, and govern the enormous volume of complex work that agents produce.\n\nA clean, legible diagram attached to an implementation plan, a pull request, or a system map can be the difference between an agentic project that is governable and one that isn’t. And if diagrams are how humans keep up, they should exploit every piece of visual / spatial circuitry we are born with: directionality, symmetry, proportion, relative positioning, color, rich text, and motion.\n\n## Why a new format\n\nFor the last two or three years, AI diagramming has been synonymous with Mermaid – deservedly. “Produce a Mermaid diagram” was a magic incantation: near-optimal tradeoffs between visual richness, speed, required model intelligence, and instruction-following, backed by copious Mermaid syntax in every pre-training corpus. It’s what opened people’s eyes to AI diagramming in the first place.\n\nBut Mermaid is a relationship language. It has no way to say where anything goes – layout is delegated to an engine by design. So the new fluency has no way in. LLMs have silently outgrown Mermaid, largely unbeknownst to the people prompting them – and, in a sense, to the models themselves.\n\nSo then, why not use an existing coordinate-aware format? We looked hard at the candidates.\n\n**SVG and HTML** are coordinate-native but too low-level. A box with a label is a pile of paths and tspans; there is no node, no edge, no group – nothing to validate against, and no way to move a box without recomputing every line attached to it.\n\n**Draw.io XML** has the right semantics but was designed as a GUI’s save format, not a generation target: verbose, cryptic, and expensive in tokens.\n\n**Graphviz, D2, and PlantUML** are excellent relationship languages that, like Mermaid, hand layout to an engine.\n\nAnd yes, we know that ours is yet another standard. And our bet is that *semantic nodes and edges, plus explicit coordinates, plus strong defaults, designed for token-efficient LLM emission* is a genuinely unoccupied point in this space – not a fifteenth standard for an occupied one.\n\n## What it looks like\n\n```\n{\n  \"entities\": [\n    { \"tag\": \"Icon\", \"id\": \"client\", \"icon\": \"user\",\n      \"x\": 190, \"y\": 40, \"texts\": [{ \"text\": \"Client\" }] },\n    { \"tag\": \"Group\", \"id\": \"vpc\", \"color\": \"blue\",\n      \"x\": 40, \"y\": 190, \"width\": 420, \"height\": 190,\n      \"title\": { \"text\": \"Production\", \"icon\": \"server\" } },\n    { \"tag\": \"Icon\", \"id\": \"api\", \"icon\": \"node\",\n      \"containerId\": \"vpc\", \"x\": 190, \"y\": 270,\n      \"texts\": [{ \"text\": \"Orders API\" }] },\n    { \"tag\": \"Icon\", \"id\": \"db\", \"icon\": \"postgres\",\n      \"containerId\": \"vpc\", \"x\": 350, \"y\": 270,\n      \"texts\": [{ \"text\": \"Postgres\" }] }\n  ],\n  \"connections\": [\n    { \"from\": \"client\", \"to\": \"api\",\n      \"label\": \"HTTPS\", \"endArrowhead\": \"triangle\" },\n    { \"from\": \"api\", \"to\": \"db\",\n      \"label\": \"reads\", \"endArrowhead\": \"triangle\" }\n  ]\n}\n```\n\nThree principles shaped the design:\n\n**Trivial to bootstrap.** Strong defaults for styles, icons, spacing, and typography mean an LLM – or a human – can emit a handful of lines of JSON and get something presentable. Icons resolve by name, connections route themselves, and a PNG falls out the other end; none of it needs extra code to wire up.\n\n**Deeply customizable.** Every default is overridable – styling, connectors, animation (coming soon) – and you can define your own components. A tag is simply a schema plus markup and CSS. You can add a custom card shape, a UML class box, or a Gantt bar. Or narrow instead of extend: restrict which colors are legal, or bundle styling into named variants.\n\n**Inert by default.** LLM output you intend to render can be an attack surface if it needs to be computed. However, since JSON is data, not code, it can be schema-validated before anything touches a browser. Our component dialect deliberately cannot compute: no arithmetic, no string building, no arbitrary execution. Icons are sanitized fail-closed. You can safely accept the diagram output even though you don’t control the LLM that created it.\n\n## Why we’re open sourcing it\n\nBecause it’s the fastest way to the largest impact. If human comprehension is the bottleneck on human–agent collaboration, the fix shouldn’t live inside any one product. We want this format everywhere an agent needs to show a human what it did: agent frameworks, PR bots, documentation pipelines, and IDEs.\n\nAnd here’s the candid business logic: we’re commoditizing the format and betting we can build the best tools and services on top of it. MIT licensed, free for commercial use, closed to contribution.\n\nThe spec, renderer, and examples are at [github.com/eraserlabs/eraser-diagrams](https://github.com/eraserlabs/eraser-diagrams). Tell us where it breaks.", "url": "https://wpnews.pro/news/open-sourcing-eraser-diagrams", "canonical_source": "https://www.eraser.io/blog/open-sourcing-eraser-diagrams", "published_at": "2026-09-08 18:36:38+00:00", "updated_at": "2026-09-08 18:48:59.229735+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "generative-ai"], "entities": ["Eraser Labs", "Eraser Diagrams", "Mermaid", "ELK", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/open-sourcing-eraser-diagrams", "markdown": "https://wpnews.pro/news/open-sourcing-eraser-diagrams.md", "text": "https://wpnews.pro/news/open-sourcing-eraser-diagrams.txt", "jsonld": "https://wpnews.pro/news/open-sourcing-eraser-diagrams.jsonld"}}