Start in Cloud or bring your existing codebase. Continue in your editor.
Let LibraOS run the agents, memory, knowledge, and tools.
Extension in Preview · SDK and application source on GitHub
Your interface.
Your business logic.
Your Git history.
Adapt the starter or connect an existing app. Keep the source in your GitHub repository and continue with your editor and coding tools.
Explore the starter source ↗A response informed by your documents and saved preferences.
Your frontend handles the experience. Your configured model and LibraOS Runtime handle agent execution, retrieval, memory, and tool use.
Compile and run the starter →Use the VS Code extension to inspect agents and memory, debug retrieval, and follow Runtime logs as you improve your application.
Explore the extension →Start a project in Cloud, adapt the local starter or integrate the Runtime into an existing codebase.
Customize a working starter. Build the interface and business logic your product needs.
Choose a client project →Keep it in your repository. Branch, review, and develop in VS Code with your usual tools.
Connect your editor →Test with a local Runtime, then configure hosting, authentication, and routing for your infrastructure.
Get the Runtime →VS Code extension · Preview
Connect a model, start the local Runtime, and wire it into your project. Then inspect your agents, memory, and retrieval without leaving VS Code.
VS Code 1.95+ · Docker Compose v2 · A compatible model endpoint. Install from VSIX; the extension is not yet on the Marketplace.
In Extensions, choose “Install from VSIX…” and select the downloaded file.
Choose an endpoint and model. Test the connection before saving.
Choose Install Runtime, then Run Local Runtime.
Generate project configuration and a quickstart, then run it in the terminal.
Start with the Personal Assistant: a React + TypeScript app with sign-in, streaming chat, conversation history, document Q&A, and memory. Use it as the foundation for your one-sentence build prompt.
Clone the cookbook and prepare its local configuration. The app source stays in your project.
™git clone https://github.com/libraos/cookbook.git libraos-cookbook
cd libraos-cookbook
cp get-started/.env.example get-started/.envEdit get-started/.env using the setup guide: model and embedding endpoints, local secrets, demo password, and sign-in callback. Keep credentials in your local configuration.
After configuring the environment, start LibraOS and register the starter app and demo user.
cd get-started
docker compose up -d
curl --fail http://localhost:8900/health
cd ..
bash apps/personal-assistant/scripts/setup.shThe reference stack includes its database. Check the app README for model, memory, and document-indexing settings. Already run LibraOS? Adapt the app registration and connection settings to your instance.
From the cookbook root, install dependencies, type-check and compile the frontend, then serve the built app locally.
cd apps/personal-assistant/web
npm ci
npm run build
npm run previewOpen http://localhost:5180. Sign in as demo@example.com with the demo password you configured. Keep LibraOS running; the preview server forwards API requests to it.
Ask the assistant a question. Upload a document and ask about it in a new chat. Then check recall in another conversation. Your configured model and Runtime handle the response; the frontend build checks the application code. For production, configure hosting, authentication, and API routing for your environment.
AI products with agents, memory, knowledge, and tools. Your application owns its interface and business logic. LibraOS supplies the runtime beneath it. The website shows application concepts. Cloud identifies available templates and builds projects from your brief; the Cookbook provides a runnable local starter.
Yes. Start with the Self-Hosted binary for your platform. Air-gapped operation requires local models and connectors, plus validated network and storage configuration. For a hosted option, LibraOS Cloud is in private beta.
You keep control of the code and business logic you write for your application. Configure compatible model providers and your own credentials; verify support for the models and tools your workflow needs. Runtime licensing is described on the pricing page.
Yes. Keep your application in your own Git repository and use your normal branch, review, and commit workflow. Open it in VS Code and use the LibraOS extension to configure and inspect the local Runtime. GitHub sign-in is separate from repository access; there is no repository-sync action on this website.
The extension sets up and connects the Runtime. Your editor or coding assistant helps you write application code. The extension is in Preview; inference credits and Cloud Deployment are not available in it yet.
The controlled Runtime benchmark measures framework overhead with a mock model. The real-model W10 reports measure specific task outcomes and costs separately. Neither establishes superiority across all production workloads.
Configure permissions, approval points, and audit for the execution path your application uses. External framework tools require separate enforcement. Review security and deployment boundaries and licensing, or contact the team for enterprise requirements.