Grounded answers, cited reports, and working apps — on models you run yourself.
Disco is a self-hosted platform for research and building: cited answers, full reports with sources you can check, and a coding agent that works in a sandbox. Built to run well on open-weight models on your own hardware, not only on frontier APIs.
✓ Apache-2.0 — and the license will never change. · Benchmarked on DeepResearch Bench against Gemini Deep Research, Perplexity, and Claude Research, and on App-Bench against Codex, OpenHands and Dyad — see the numbers.
See Disco at work
From a question to something you can use.
A short tour of research, application building, and agent tasks.
Four surfaces · one engine
One engine. Four ways to work with Disco.
Search, Deep Research, Build, and Agent share one engine and one record of everything the agent does. Pick the surface that fits the job; the guarantees are the same everywhere.
Search
Answers that show their work
One clear answer, with every claim tied to a passage in a source you can open. Claims the sources don’t back up are marked, not hidden. When the evidence is weak, you can see that.
Deep Research
Reports with receipts
Disco plans the investigation, searches and reads until the gaps are closed, then writes a cited report and checks every claim against its source. Choose how deep to go, replay the whole run, and take the result out as a PDF, a slide deck, or an audio overview.
This is the surface we benchmark below.
Same report, three ways out
A finished Deep Research report can leave Disco in the form that fits the room: a typeset PDF, a slide deck, or an audio overview to listen to on the way in. These three came from one report on Python’s free-threaded build, exported as Disco produced them.
The report as slides
Press Build a deck on a finished report; Disco writes and lays out the slides, ten here.
“Benchmarks show a clear trade-off. In the 3.13 free-threaded build, single-threaded performance is about 40% slower… By 3.14, that penalty drops to around 10%.”
The report, read aloud
A narrated audio overview, one voice or two hosts, on the bundled local voice.
40 s of a 7-minute overview
Build
Build the interface. Build what makes it work.
Build a searchable directory, a customer portal, a records dashboard, or a site with forms, subscriptions and a blog. Disco gives the agent reusable application components alongside a shell, browser, live preview and workspace history. The agent connects the behavior, checks it in the browser, and runs verification and design lint.
What goes into an app
Working parts you can combine.
Describe the flow you need. Disco can use its built-in components to give it data, actions and content, then write custom code around them.
- Forms & lead capture
- Validated fields, submission storage and a way to review incoming inquiries.
- Directories & collections
- Searchable listings, filters, detail views, team profiles, menus and other structured content.
- Records & accounts
- Related data, create/edit/delete flows, sign-in and access policies for customer portals and internal tools.
- Publishing
- Blog posts, RSS feeds, page metadata and sitemaps alongside the rest of your app.
- Payments & integrations
- Stripe checkout and entitlements, plus authenticated webhooks. Connect your own service accounts when you want to go live.
- App operations
- First-party page analytics and feature flags, with the configuration documented in the generated project.
Take the whole app with you
Download it. Run it with Docker Compose.
For supported web apps, Disco packages the source with the services it needs: Dockerfiles, a Compose file, environment-variable setup and self-hosting instructions. Keep the project on your machine or move it to your own server.
The export panel tells you whether the bundle has been runtime-verified or still needs review. See the export workflow.
Inside a self-host bundle
your-app/ compose.yaml Dockerfile .env.example SELFHOST.md release.json …your source files
Follow SELFHOST.md, set the required environment variables, then:
docker compose up -d --build
Services, health checks and declared persistent volumes travel with the app.
Agent
The same agent, pointed at any task
Everything Build can do, for any task on your files and tools. Add tools through MCP servers and keep each one on a short leash: you approve what a tool may do, its output is fenced off, and its web access goes through the same allowlist as everything else.
Built with Disco
Four sites. Four different ways to interact.
Explore an architecture portfolio, plan a coffee order, play a synthesizer, or put together a visit to a glasshouse. These projects were built and iterated inside Disco, with feedback on the design and working interactions.
The original designs used DeepSeek V4 Flash. The expanded versions were built with Qwen3.8 Flash via OpenCode Go, continuing the same Disco projects. Each demo runs in your browser; orders, inquiries, and visit plans are demonstrations, with no payments or bookings sent.
Halde architecture studio
Search and filter six projects, open illustrated case studies, and build an inquiry brief you can save locally and download.
Northlake Roasters
Explore the coffee catalog, build a persistent cart, try the demo checkout, and use the brew calculator, timer, and subscription planner.
Voltline synthesizer
Play a working browser synth, shape the sound, program a 16-step sequence, and save or exchange your own presets.
Marrow Glasshouse
Explore the conservatory and its specimens, browse seasonal events, and save or download a visit itinerary.
Download all four demo projects · includes source and Docker Compose files · SHA-256 checksum
Local first
Engineered for the models you run, not just the ones you rent.
Most agent stacks assume a frontier API and fall apart on a 27B model. Disco was built the other way around: the reliability work is done in the system, so an open-weight model on your own hardware can do the work.
A context that stays small
Old tool output is folded away behind a reference the agent can reopen, so the model’s window stays small and stable instead of silting up.
Prompts that keep the cache warm
Prompts are laid out so their opening never changes from turn to turn. Local servers keep their KV cache hot instead of re-reading everything each step.
Fewer ways to go wrong
At each step the model is offered only the moves that make sense right then, so smaller models stay on the rails without a second model watching over them.
Done means checked
“Done” is a checked claim, not a vibe — the agent verifies the work before finishing, and every citation is checked against its source before shipping.
No API keys needed. Web search, page extraction, embeddings, reranking, citation checks, and text-to-speech all run locally out of the box, on CPU, AMD included. Point Disco at Ollama, llama.cpp, vLLM, LM Studio, or any OpenAI-compatible endpoint, and add paid providers only if you want them.
The receipts
~3,900 recorded runs before Disco asked for anyone’s trust.
From the first overnight autonomous run in June to the final certification wave in August, every test run was recorded, every failure replayed and traced to its cause, and the whole history is published — index, lineage, and all 253 failure write-ups.
The finding, every time: capable local models don’t need a bigger model watching them — they need better boundaries. Every run-ending failure traced back to the product, the test harness, or the infrastructure; fix the boundary and the same model sails through. Each certificate is tied to a sealed record of its runs, so the claims can be checked, not just read — read the full evidence history, or the philosophy it produced: Walls that make sense.
Measured, not claimed
Head-to-head with the hosted research tools.
Ten research tasks from DeepResearch Bench, run through Disco and three hosted products, then graded two ways by the same four-judge panel: report quality against a frozen human-written reference article (RACE), and whether each citation is actually supported by the source it points to (FACT). Both tracks are included in the benchmark release materials — including the ones we lose.
The models were deliberately tier-matched: Claude on Opus 4.7, Gemini on 3.8 Flash, Disco on Qwen3.8 Flash Next — all within two points of one another on Artificial Analysis’s intelligence index at the time of the runs (Perplexity doesn’t expose a model choice). With comparable brains everywhere, what’s actually being measured is the research system around them.
Report quality RACE · relative score · 50 = parity with the human-written reference
Citation support FACT · every claim–source pair checked against the retrieved page
The read, honestly: on quality, Disco lands above parity with the human-written reference and within a point and a half of the frontier products — Disco loses to Claude Research and Gemini there, and that’s printed above. On evidence, the tools split into two philosophies: Claude cites sparingly and almost perfectly; Disco cites an order of magnitude more and seven in ten citations hold up against the source — about twice the supported evidence per report of Gemini or Perplexity, and nearly seven times Claude’s, at the second-best accuracy in the field. All of it from hardware you own.
Local ten-task reproduction of DeepResearch Bench (pinned upstream tasks, references, and criteria) — not the 100-task leaderboard, so not comparable to published scores · one run per system per task, each product as shipped · system models tier-matched on the Artificial Analysis intelligence index (within 2 points of each other at run time; Perplexity does not expose a model choice) · four-judge equal-weight panel (DeepSeek v4.1 Flash, Gemini 3.8 Flash, Muse Spark 1.3, local Qwen3.8-27B); rankings are unchanged when the two judges with a family stake are dropped · FACT measures support in the retrieved source text, not the truth of claims · sealed 2026-09-16: every rendered prompt, all 19,324 citation judgments, raw model logs, retrieval artifacts, and checksums ship with the release · methodology & benchmark source files
Head-to-head with the coding agents and app builders.
Six full-stack apps from App-Bench — a Bloomberg-style dashboard, a hospital patient board, a legal assistant, a pharmacy system, a multiplayer drawing game, a rental marketplace — each built in one shot from the same frozen prompt, with the same model everywhere (DeepSeek V4 Flash), the same offline reference packs, and the same registry-only network. Every app was then deployed and clicked through blind, under a random label, against the 151 binary rubric items: a feature counts only if a user can reach it.
Verified rubric items App-Bench · six tasks · share of the items that passed a hands-on check, over the 136 items checkable for every system
Per task verified share of that task’s checkable items · Disco, Codex, OpenHands, Dyad
The read: Codex leads, and that is printed above. Disco is second, delivers a running app on all six tasks, passes more than three quarters of what the rubric asks for, and wins the hospital board and the drawing game outright. OpenHands shipped nothing that starts on three of six tasks; Dyad shipped its untouched starter template on five and an app whose screens never mount on the sixth. Every system had the same model, the same documents, the same network and the same two-hour cap.
Six App-Bench tasks, frozen prompts, one build per task, no steering, two-hour cap · DeepSeek V4 Flash (July-31 release) for every system, same offline vendor reference packs, every build behind the same filtering proxy (package registries and the model endpoint only) · grading blind: each app copied under a random label, one grader per app, deployed and exercised through the UI with a screenshot per check and a restart for persistence · the same services withheld everywhere (market data, web search, embeddings, transcription, payments, hosted databases); an item that could not be verified for any one system is excluded for all, leaving 136 of 151 items comparable · not an official App-Bench score (one attempt, one grader) · item-level grades, screenshots and build logs kept for every app; disclosed deployment and grading exceptions are recorded in the fairness report · methodology & benchmark source files
The one idea underneath
Disco writes everything down. Nothing gets rewritten.
Searches, steps, and approvals all go into one running record as they happen. Nothing is edited after the fact. When a session runs long, older detail is summarized for the model and the original stays on file. That one habit buys the rest:
- Replay — watch any run again, step by step.
- Resume — pick up where you left off after a dropped connection, even if the sandbox had to be rebuilt.
- Audit — every claim, action, and approval can be pointed to later.
- Long sessions stay sharp — the model works from a tidy summary while the full history stays intact.
Sandboxed by default
Agents work inside an isolated sandbox that can reach only the sites you allow. Several sandbox types are supported, from a rootless container to a hardened one.
Secrets stay home
Tools are given permission to act on your behalf, never your credentials. Your keys stay encrypted on Disco’s side of the wall and never enter the sandbox.
Honest citations
Every report is checked claim by claim against the sources cited. Anything a source doesn’t actually support is flagged or dropped — in the open, not silently.
The promise
Disco will not be relicensed to a source-available, fair-source, BSL, SSPL, or commercial license — not as Disco grows, not after adoption, not on acquisition. Every past and future release stays Apache-2.0. The whole point of this project is to be the trustworthy one you can self-host; a license rug-pull would break that promise, so we don’t reserve the right to make one.
— the license section of the README, permanently
About
Built by one person, in the open.
Hi — I’m Dylan. By day I’m a critical facilities engineer at one of the hyperscalers. Before that I was in the Navy, maintaining autonomous weapon systems. Working on systems where reliability matters has shaped how I approach Disco: understand what the system is doing, make failures visible, and verify the work.
Disco started with curiosity about the agent products I enjoyed using. I wanted to understand how they worked and see how far I could take the idea with models running on my own hardware. That grew into a place to research a question, build an application, and follow what the agent did along the way.
It took four months of building with AI — and rebuilding, more than once. Getting something to work was the beginning; figuring out why it failed on the next run became much of the work. The testing, evaluations, and execution records grew out of that process. They are how I check whether a change actually helps.
The curiosity extends below the application, too. I run models on a dual-R9700 workstation, and working with them led me into kernels and quantization tooling for RDNA4. I enjoy being able to follow a problem from what appears on screen down to how the model runs.
I’m sharing Disco so other people can run it, look inside, and build on it. There is a lot I’m still learning, and having something concrete to experiment with is a big part of the appeal.
Quickstart
From clone to running in three steps. No .env required.
Bring Disco up. One command starts the app, the agent, the web UI, the bundled encoders, and text-to-speech.
Sign in. Open localhost:8088 and paste the one-time admin token from the logs.
Point Disco at a model. Ollama, llama.cpp, vLLM, LM Studio, or any OpenAI-compatible endpoint — then run disco-verify --quick to confirm everything is wired up.
# rootless Podman (the tested path; see docs for Docker) curl -fLO https://github.com/Dyluhn/disco-releases/releases/download/v0.2.0/disco-source-v0.2.0.tar.gz curl -fLO https://github.com/Dyluhn/disco-releases/releases/download/v0.2.0/SHA256SUMS sha256sum --ignore-missing -c SHA256SUMS tar -xzf disco-source-v0.2.0.tar.gz cd disco-v0.2.0 systemctl --user enable --now podman.socket export DISCO_SANDBOX_SOCKET=$XDG_RUNTIME_DIR/podman/podman.sock podman compose -f compose.yaml -f compose.build.yaml up -d --build podman compose logs app-server # prints the UI URL + pairing token
Source preview. These commands build the released source locally. Prebuilt container uploads are still pending. Release status and checksums.
Runs in 8 GB of RAM with the lite encoders; 16 GB for full local retrieval quality. A 24–32B instruction model with a 32k context window makes a good local driver. Windows via WSL2 or Docker.