Who it is for
Developers and operators evaluating a local website-building workflow, with explicit provider configuration and source setup requirements.
Quesar / Model vision
Research toward a shared model layer.
Quesar is the model vision for Abbey, Aviva, and the assistant ecosystem. Explore the research direction alongside the source and tools available today.
PartialPublic orientation and a signed-in console are current. A trained Quesar foundation model, training results, and hosted assistant sessions remain unqualified here.
What it is
A system you can place, inspect, and bound.
Quesar exists because intelligence that forgets you at the end of every session is not a foundation you can build on — and intelligence that requires you to surrender memory to a remote cluster is not a foundation you should have to accept.
How it differs
The experimental Quasar builder combines browser pairing, an operator-owned service, and a configured generation provider. ABI, WDBX, and Abbey are separate source projects; this builder does not establish a training pipeline between them.
What you can build
The Quasar service scaffolds Next.js projects and implements provider-assisted file edits and a local preview. Live provider generation requires separate acceptance. ABI tools and WDBX retrieval have their own source and integration requirements.
What you cannot assume
The static website provides orientation and browser previews. A configured server separately supports consent-gated console chat; the Quasar browser client requires a running paired service for generation. Neither surface establishes a hosted Abbey product session, a managed deployment service, or live provider acceptance.
Name
Quesar names the model vision. Quasar is the local builder.
They are not interchangeable. This repository keeps the builder service at sidecars/quasar-service and its screens at /quasar/sites; the website is this app.
Quesar
A long-term model direction for Abbey, Aviva, and related assistants, with public research and source to inspect. This site provides orientation and does not run model training.
Quasar
A local website builder with a Bun service and browser client: pair with an exact service origin, configure generation, and preview a generated Next.js project on your machine. Hosted deployment and live-provider acceptance remain separate.
Quasar v1
Four parts. Preview means next dev on your machine.
From the integration README. Unit suite is not a live Anthropic generation.
- 01
packages/shared
TypeScript types and zod schemas shared by the service and the Expo app — Site, GenerationEvent, PreviewStatus, request bodies.
- 02
sidecars/quasar-service
Local Bun service (default port 4700): registry, path guard, site filesystem tools, generation engine, scaffolder, preview manager.
- 03
templates/next-site
A buildable, checked-in Next.js 16 + Tailwind v4 starter, copied per-site as the generation baseline. Own lockfile, outside the root workspace.
- 04
/quasar screens
Sites, new site, site detail with live events and preview, and settings, in this app. They call the local service from your browser. There is no deploy step in v1.
sidecars/quasar-service
bun run --cwd sidecars/quasar-service start
# pair the browser with the operator-owned service token
# see sidecars/quasar-service/README.mdStudio
Prompt to a preview.
Browser scaffold only. Real generation needs the local Bun service and Anthropic credentials.
next dev · local
Surfaces
What exists in public source today.
| Surface | Role | Status |
|---|---|---|
| This website | Product orientation and source setup links | Current |
| Local site builder (Quasar) | Experimental browser client paired to a local Bun service; generation requires Anthropic credentials | Experimental |
| Abbey workspace | Browser document preview with localStorage documents and an optional configured server model-request path | Current |
| Mobile companion | Browser vault preview uses localStorage; separate Capacitor source is not signed-device sync acceptance | Partial |
| Hosted Quesar cloud | Managed sessions, generation, authentication | Planned |
Builder data and generation requests require a pairing token bound to the service origin. Remote service origins require HTTPS. In-browser studio above. Setup notes: getting started.
Next