ASCIITermDraw-Bench
ASCII Diagram Generation and Editing Benchmark
Evaluate whether a model can generate ASCII diagrams in plain text. ASCIITermDraw-Bench measures box layout, topology construction, software architecture sketching, and image-conditioned ASCII editing with tasks spanning real world applications, topologies, clusters, and diagram editing in increasing level of difficulty evaluated using structural and semantic based scoring, and model-specific LLM-As-A-Judge prompts.
- Organized task categories
- Reproducible generators
- Playwright rendering
- Together AI batch inference
- Structural (JSON) + Semantics LLM-As-A-Judge (DeepEval)
Overview
ASCIITermDraw-Bench is a benchmark for structured ASCII diagram generation and editing. Instead of grading models on prose quality alone, it checks whether they can place labels, preserve spacing, route arrows, maintain overall structure, and make constrained edits to an existing diagram.
The benchmark covers four families of tasks:
- Box Layout Basics: single boxes, rows, columns, arrows, and spacing-sensitive layout
- Network Topology Diagrams: clusters, buses, data flows, and connection topology
- Diagram Editing: image-conditioned edits applied to an existing ASCII diagram
- Software Architecture Diagrams: real-world gateways, pipelines, feeds, and storage layers
Every task ships with a prompt, a reference ASCII artifact (a PNG to be rendered), and structured assertions.
Every candidate diagram is judged through an LLM-as-a-judge pipeline: a DeepEval BaseMetric judge
(OpenAI or Anthropic), following the
shared judge prompt,
scores each candidate against the reference on two axes, averaged over multiple judge rounds and
combined into the final geval_score:
- Structural score: do the required labels, entities, and edges actually appear, checked against structured assertions.
- Semantic score: does the layout, spacing, and connection routing actually match the prompt.
Leaderboard
outputs/<model>/metrics.json and
scripts/judge/compute_metrics.py for the exact
methodology. More rows will appear as more models are benchmarked.
Task Categories
| Category | What it measures |
|---|
Benchmark Anatomy
prompt.txt (plus source.png for editing tasks).txtresults.csv and gval/result.json per task
Category 3 is multimodal: the model receives a rendered source.png and must apply a textual edit
instruction while still returning plain ASCII. The remaining categories are text-to-ASCII generation tasks.
Judge / GEval Process
BaseMetric call (GPT-5.4 or Claude Sonnet 5), repeated num_judgments times (default 5) per taskassertions.jsonoutputs/<model>/results.csv and gval/result.json per task
Every candidate is judged num_judgments times independently (not cached
repeats) so the reported score is a mean across rounds with a population stdev, not a
single noisy judge call. See the Leaderboard for
published results and metrics.json for the exact methodology notes.
Key Features
Benchmark Coverage
- Box Layout Basics - simple boxes, chains, stacks, fan-in, fan-out, diamonds, and spacing-sensitive arrangements.
- Network Topology Diagrams - brokers, parameter servers, service meshes, CDNs, DNS flows, and cluster communication patterns.
- Diagram Editing - image-conditioned edit tasks that require preserving the original structure while applying the requested change.
- Software Architecture Diagrams - 3-tier systems, event pipelines, API gateways, queues, ETL layouts, and other canonical engineering sketches.
Inference Pipeline
Generation follows the flow shown in Benchmark Anatomy: a task's
prompt.txt (plus source.png for editing tasks) goes to Together AI for
model inference, producing raw ASCII output, which is then rendered to a diagram-only PNG before
being handed to the judge.
- Playwright PNG rendering: reference ASCII artifacts are rendered as diagram-only images for editing tasks and visual inspection; see Technical Details.
- Together AI generation: model responses and rendered PNGs only; Together is not used for judging.
Evaluation Pipeline
BaseMetric judge (OpenAI or Anthropic), following the
shared judge prompt,
reports an structural score and an
semantic score per task:
geval_score = geval_structural_score + geval_semantics_score. There is no separate
deterministic/text-heuristic scoring step.
Judging follows the flow shown in Judge / GEval Process:
- Candidate and reference PNGs, plus the judge prompt and
assertions.json, go to the judge. - The judge round repeats
num_judgmentstimes (default 5). -
Structural score: harness-computed, not judged directly.
The judge reports what it observes; the harness checks each observation against
assertions.jsonas an independent, all-or-nothing component (no partial credit within a component), then averages whichever of these apply to the task:required_labels: every required label appears somewhere in the diagram.entity_count: the observed entity count matches the expected count exactly.required_edges: every required connection is present.required_edge_labels: editing tasks only, every required edge label is present.preserved_elements: editing tasks only, elements that should survive the edit still do.
-
Semantic score: the judge's own direct 0.0-1.0 rubric
judgment, informed by its own checks on:
connections_correct: are the connections actually made where they should be.text_inside_nodes_correct: is the text inside each node/box correct.text_centered_in_nodes: is that text centered within its node/box.labels_spelled_correct: are all labels spelled correctly.arrows_cleanly_aligned: are arrows cleanly aligned to their source and target.layout_matches_prompt: does the overall layout follow the prompt.
- Both scores are averaged across rounds and summed into
geval_score.
- Repeated judging: each task can be judged multiple times (default 5) with mean/stdev reported, to separate real quality differences from judge-scoring noise.
- Repository-first organization: task directories, scripts, outputs, and website metadata are all arranged for extension and public contribution.
Example Tasks
One hard-difficulty task per category, loaded live from the public Hugging Face dataset (the same format as the private benchmark). Click a diagram to view it full size, or see every public example on the Tasks page.
Technical Details
Task assets live in named category directories, and the website data is built directly from the
repository tree (see
website/tools/build_site_data.mjs)
rather than from hand-maintained content.
Rendering
Every ASCII artifact (reference or candidate) is rendered to a diagram-only PNG by
scripts/rendered/render_ascii.mjs:
headless Playwright/Chromium loads the raw text into a monospace <pre> element on a
minimal page, resizes the viewport to exactly fit that content's bounding box, and screenshots only that
region at 2x device scale. There is no surrounding page chrome in the output, just the diagram itself.
Inference and Scoring
- Smoke generation: synchronous shared-module Together AI calls for fast spot checks on a random subset of tasks.
- Full generation: the same synchronous Together AI transport, run across all tasks.
-
DeepEval judge: a custom
BaseMetricagainst OpenAI or Anthropic, following the shared judge prompt. Structural score verifies visual evidence againstassertions.json; semantic score comes from a task-specific rubric prompt.
Benchmark Summary
A compact view of the benchmark coverage before diving into the full detailed task listing.
| Category | Tasks | Difficulty Buckets |
|---|
Documentation
Core entrypoints and artifacts for working with the benchmark:
- Quick Start Guide - environment setup, rendering, smoke tests, batch runs, judging, and local website preview
- Task Metadata - generated category and task index consumed by the published website
- Tasks - full detailed task inventory generated from the benchmark repository
- Technical Details - inference, rendering, scoring, and repository-structure notes
Publishing Notes
The website is static and GitHub Pages-ready. Its data file is generated from the real task tree, so publishing the site also publishes the benchmark structure.
Contributions are expected to happen through the repository itself: new tasks, improved judges, better renderers, and stronger evaluation baselines can all build on the same layout.