Join Beta

Turn your ideas into AI apps.

Describe what you need. Build with AI, then deploy to the cloud or run locally.

Powered by LibraOS Runtime Agents, memory, knowledge, and tools.

Try the starter app →

Continue in LibraOS Cloud to create your project and start its first build. Eligible accounts can also export the source and continue locally.

Idea → app

Animated concept. Your coding agent builds the actual app.

Cloud unavailable? Use the build prompt locally
  1. Describe

    Start with your app idea.

  2. Generate

    Cloud creates the project and starts the build.

  3. Run

    Deploy to production or export and run locally.

Think. Remember. Act.

LibraOS runs the agents, memory, knowledge, and tools in your app. Try these interactive concepts with sample data.

INTERACTIVE PREVIEW
AI-powered CRM & Ticket Management
#TK-2041Needs reviewSample data

Replacement shipment for order #DM-1042

CUSTOMER REQUEST

The replacement hasn’t arrived. Can you check the latest delivery update and tell us what happens next?

High priorityOwner · Demo teamFictional sources
Preview only · not sent
Interactive concept. No live customer data, AI request or outgoing message.
Interactive product concept · sample data, not a connected AI serviceAgents   /   Memory   /   Knowledge   /   Tools

What will you deliver?

Start with a common client project. Adapt it to their workflow.

Industry examples

Application concepts. Cloud shows which have verified templates. Want running code? Build the Personal Assistant starter →

Inside the Runtime.

Explore Runtime ↗

Agents

Coordinate tasks and connect tools.

Memory

Carry useful context across sessions.

Knowledge

Retrieve from your connected sources.

Control

Define policies, approvals, and audit.

An AI Runtime.
Measured overhead.

Add AI to an existing app or build from a starter. Keep your source in GitHub, continue in your editor, and run LibraOS on your infrastructure.

Own your application codeVersion controlDeployment choiceBYOK
Controlled Runtime benchmark
244 runs/s

256 concurrent runs · approximately 3.8× Agno in the Minimal Runtime test.

52 MB idle RSS

LibraOS v0.2.2 · fresh database. See peak memory and comparator measurements.

10.9 ms CPU/run

Sequential mock-model test. Compare both Minimal and Production configurations.

Explore Benchmark

Controlled mock-model test at 256 concurrency: LibraOS 244 runs/s, Agno 64, LangGraph 8. LangGraph used langgraph dev; polling affects throughput. These results do not establish production deployment superiority.

Choosing a platform for your AI product?

Compare application delivery, Runtime governance and deployment options.

Why LibraOS & comparisons →

Choose where it runs.

Self-host on your infrastructure or request access to LibraOS Cloud. Test your models and application services with your chosen setup.

LibraOS Self-Hosted

Run on your infrastructure, with your choice of models. The setup wizard helps configure agents, knowledge, and permissions.

Download & setup requirements →

LibraOS Cloud

A hosted edition in private beta. Request access for your team, or discuss private infrastructure and local models with us.

Join the private beta →

Deploy with control.

Discuss private deployment, security requirements, and OEM licensing.

Explore enterprise security
← Back to homepage

The AI Runtime
for your app.

Run agents, retrieve knowledge, remember context, and connect tools. LibraOS provides the AI execution layer; you build your product’s interface and business logic.

Build your first app →View Benchmark →
YOUR APPLICATION

Your product. Your code.

Interface · domain logic · data model · approvals

↓ execution requests & context ↑ results & events
LIBRAOS RUNTIME

Coordinate the work.

AgentsMemoryKnowledgeScheduling
configured connections, explicit boundaries
MODELS & APPLICATION SERVICES

Model endpoints · tools · storage · infrastructure

Understand Runtime overhead.

Evaluate Runtime overhead with documented tests, then measure your own application’s latency, task quality, and resource use.

Coordinate parallel work.

Run multiple application tasks concurrently. Use the Benchmark to compare throughput and tail latency under the recorded configurations.

Keep overhead visible.

Inspect memory, CPU, and startup costs. Runtime measurements are reported separately from model inference and supporting services.

Schedule application tasks.

Coordinate tasks and state as work progresses. Tune the setup for your workload and inspect failures along the way.

Choose your integration path.

Policy and audit coverage follow the path a request actually takes. Connecting a model does not transfer control of an entire external framework.

NATIVE EXECUTION

Work through LibraOS.

Native application tasks use the LibraOS execution path for orchestration and configured control points. Validate approval, state and audit behavior for each workflow before production.

Application business rules and human decisions remain explicit product responsibilities.
EXTERNAL FRAMEWORKS

Connect external frameworks.

When an external framework routes model requests through the configured LibraOS integration, policy and audit apply at that model-request boundary.

External tool calls, shell commands and network traffic are not automatically governed. They require separate integration and enforcement.

Run your first app.

Use the SDK or VS Code extension, connect your models, and run the Personal Assistant starter. Keep developing in your own repository.

Developer guide →   Downloads & setup →

Compare Runtime performance.

Compare controlled Runtime measurements against Agno and LangGraph. Review the configurations, methodology, and downloadable evidence.

Explore Benchmark →
← Back to homepage
Controlled Runtime Test

Controlled Runtime
Benchmark.

Throughput and resource use at up to 256 concurrent runs, compared with Agno and LangGraph using a mock model.

256 concurrency244runs/s
Idle memory52MB · RSS
CPU per run10.9ms · sequential

LibraOS v0.2.2 · Minimal Runtime · Mock model

Throughput at 256
Concurrent Runs

LibraOS vs Agno vs LangGraphHigher is better · runs/s

LibraOS244 runs/s
Agno64 runs/s
LangGraph*8 runs/s

3.8× Agno’s throughput in this controlled test.

* Mock-model framework benchmark. LangGraph was tested with langgraph dev, whose polling configuration affects throughput. Results do not establish production deployment superiority.

Minimal Runtime: baseline configurations. Agno uses in-memory storage without tracing; LangGraph uses its development server. These are different serving paths, not equivalent production deployments.

Test configurations & reproducibility ↓Download exact measurements ↗

Memory, CPU & latency.

Memory, CPU, cold start and execution latency, compared on the selected Runtime profile. Lower is better; the complete table includes trade-offs.

Minimal Runtime · controlled mock-model test
MeasurementLibraOSAgnoLangGraph*
Idle memory · RSS51.7 MB142.9 MB156.8 MB
Peak memory · 256 concurrency463.1 MB447.1 MB680.6 MB
CPU per run · sequential10.9 ms18.55 ms56.6 ms
Cold start → first run2.01 s3.44 s3.63 s
Sequential latency · p509.9 ms24.1 ms1000.9 ms
Latency at 256 concurrency · p953.094 s4.295 s41.538 s

LibraOS has lower idle RSS, but its peak RSS at 256 concurrency exceeds Agno’s (463.1 vs 447.1 MB). LangGraph’s development-server polling affects latency. The full concurrency sweep recorded 4 LangGraph failures at 128 concurrency; all three recorded 0% failures at 256.

RSS is framework-process-tree memory, excluding separately hosted services and model inference. The source report labels binary MiB (2²⁰ bytes) as MB. CPU/run comes from the sequential test, not the 256-concurrency test. LibraOS RSS also depends on database size: approximately 50 MB on a fresh database versus 246 MB on a 2.3 GB shared database.

How we measured.

These results apply to the recorded configurations. They do not establish superiority across production workloads.

Environment & versions

Recorded environment
17 October 2026 · Ubuntu 20.04.3 LTS
Hardware
AMD EPYC 7402 · 48 threads · 1,007 GB RAM
Frameworks
Agno 3.1.4 · LangGraph 1.2.16
LibraOS builds
Minimal: v0.2.2 (caba8f0f)
Production: main 41aaeca
Runtime services
Python 3.12.13 · Docker 20.10.21

Controlled Runtime protocol

  • Scripted mock model with 0 ms added delay; no real LLM inference.
  • Each single-turn run uses one tool call and two model calls.
  • Closed-loop concurrency: 1, 8, 16, 32, 64, 128 and 256. Each level uses 10 s warmup and a 45 s measured window.
  • Cold start: median of 3 launches through the first successful run. Sequential test: 200 runs after warmup.
  • Frameworks run sequentially in seeded randomized order. These snapshots have no repeated-sweep confidence intervals.
Minimal Runtime vs Production Profile

Minimal Runtime: LibraOS v0.2.2 in the recorded parity configuration; Agno AgentOS with in-memory storage and tracing off; LangGraph via langgraph dev --no-browser --no-reload --n-jobs-per-worker 512. Polling materially affects LangGraph’s measurements.

Production Profile: the report’s auth/persistence/guardrail configuration. Agno uses Postgres with tracing. LangGraph uses a custom FastAPI host with Postgres checkpointing and bearer auth—not the licensed LangGraph Server. LibraOS uses main 41aaeca. Both profiles still use a mock model; “Production Profile” describes configuration, not a production workload.

Changing profiles changes builds, storage and serving paths. It does not isolate the cost of any single feature. Resource measurements exclude separate databases, tool servers and model processes; they are not total infrastructure costs.

Reproduction & downloadable evidence

Source harness: libraos/benchmarks · benchmarks/runtime-p0. Use its service setup, dependency locks, adapter configuration and environment files before running these commands from the harness directory. The original environment capture reports a dirty checkout; source hashes are required to reconstruct it, so the repository revision alone is insufficient.

./start_services.sh
.venv/bin/python t1.py runs/t1 --profile minimal
LIBRAOS_IMAGE=libraos-bench:main-41aaeca   .venv/bin/python t1.py runs/t1-prod --profile production

Published here: aggregate result snapshots and their source paths and SHA-256 checksums. The complete harness, dependency locks and per-run logs are not bundled with this website.

The W10 downloads are separate real-model task evaluations: the corrected report and merged-fix regression use their own results, costs, and latency. They do not extend the mock Runtime comparison to general production performance.

Runtime measurements ↗Full concurrency sweep ↗Corrected W10 ↗Merged-fix regression ↗Source manifest & checksums ↗
Explore the Runtime →