cd /news/large-language-models/mosaic-a-reconfigurable-surface-wher… · home topics large-language-models article
[ARTICLE · art-35474] src=discuss.huggingface.co ↗ pub= topic=large-language-models verified=true sentiment=· neutral

MosAIc: a reconfigurable surface where an LLM emits a layout, not just text

Developer vonargo released MosAIc, a reconfigurable surface where large language models emit JSON overlays to reshape UI layouts instead of generating linear chat transcripts. The open-source project, hosted on Hugging Face Spaces, uses a viewer-billed architecture with client-side OAuth and no backend, allowing models to patch surfaces incrementally. The creator seeks technical feedback on the wire format tradeoffs between JSON, YAML, and other structured outputs.

read2 min views1 publishedJun 21, 2026

I’ve been exploring an alternative to linear chat: instead of a transcript, the model emits a small JSON overlay that re-configures the UI, and the surface lays it out. The interesting parts are the mechanism and the contract and would love some technical feedback (or thrown spears).

The core mechanism is a couple dozen lines.

A surface holds views that lay out “tesserae” (typed tiles: markdown / code / table / diagram / note / tasks).

An overlay is a surface-shaped patch, merged over a base by view id:

effective(base) = base merged with overlay, and the entire render path reads only from effective(), so one overlay reshapes the sidebar and the tiles, no imperative DOM code. The schema is deliberately tiny and it’s meant as a render target any producer (model, agent, IDE) can write to SCHEMA.md

It evolves, not regenerates (a bit simplistic right now tbh). Successive tasks are sent the current surface and emit a patch while composeOverlay() folds each into the accumulated overlay with the same id-merge, so “add a PKCE section” extends the surface instead of starting over. (Composing a patch into the accumulator yields the same result as applying it to the rendered surface, so the accumulator stays one overlay.)

Architecture is viewer-billed with no back end. Static Space, pure HTML/ES-modules, no build. The model path is BYO LLM: client side HF OAuth with Inference Providers billed to the signed-in viewer and the token never leaves the browser (no server, no owner key). The OAuth app is provisioned just from hf_oauth in the README.

Robustness. Every overlay (model or hand-edited) passes a validator that normalizes and degrades a bad emit to a message instead of breaking the render; the model path uses json_object, a balanced-brace extractor, and one corrective retry. The model is also told it has no file access, which curbs it from confidently inventing specifics about content it can’t see (though YMMV).

Open question I’d like input on: the wire format. It’s JSON today (precise, trivially validated, but models fumble escaping/brackets and it can’t stream). I wrote up the tradeoff matrix (JSON vs YAML block scalars vs markdown vs XML tags vs tool calls/json_schema) in ROADMAP.md. What have people found most reliable for getting structured UI out of a model?

MIT Licensed code and docs are in the Space tree. No signin demo via the examples: MosAIc - a Hugging Face Space by vonargo

── more in #large-language-models 4 stories · sorted by recency
── more on @vonargo 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/mosaic-a-reconfigura…] indexed:0 read:2min 2026-06-21 ·