Quesarby MLAI

Research · implementation

Quasar as a bounded repository-generation loop

Quasar couples an Anthropic tool loop to a narrowly constrained project filesystem, producing a local application through inspectable read, list, and write operations rather than granting an unconstrained shell.

AIMCPTUI

Generation loop

The service exposes three generation tools: list project files, read a project file, and write a project file. The model can iterate over tool results until it reaches a terminal response, while the service translates model, tool, and error activity into a stream of structured events for the client.

The generated project is then previewed through a local development process. This makes the artifact and the tool transcript available for inspection instead of treating a single text completion as a finished application.

Filesystem boundary

Project paths reject absolute inputs, parent traversal, repository metadata, dependency trees, and build-output paths. Existing ancestors are resolved through real paths to detect symlink escapes, and file reads have an explicit size ceiling.

Those controls reduce the authority of the model loop to a designated project root. They are a concrete example of separating generative capability from ambient workstation access.

Limitations

  • The committed profile is a local development system; it does not establish multi-user isolation, authentication, billing, hosted deployment, or production sandboxing.
  • The documented client transport polls an event stream rather than proving true server-sent streaming, and source inspection is not a live Anthropic generation receipt.
All implementationsMobile Vault persistence across CloudKit and local fallbackAbbey capability claims as an executable ledger
Research index

Next

AI overview

The track note this case sits under.