The AI Application Platform

Build AI products.
Run them anywhere.

Create with AI or develop in your stack. Deliver applications with a shared Runtime and control over models and deployment.

Explore Developer Platform Explore the platform

Runtime is currently free for development and standard production. License terms apply. Runtime binaries: Linux x86_64 / ARM64.

Your AI application

Your interface, workflow and code.

LibraOS Runtime

Agents · Memory · Knowledge · Tools

Your models. Your infrastructure.
Configured permissions, approvals and audit.

Where will you start?

Create an AI appCloud · Private beta →Deliver for a clientAgency projects and handover →Integrate into your SaaSDeveloper Platform · SDKs & APIs →Deploy for an enterpriseInfrastructure and control →

AI inside the workflow.

Explore an application concept with sample data. No live AI calls or customer records.

INTERACTIVE PREVIEW

#TK-2041Needs reviewSample data

Replacement shipment for order #DM-1042

Demo Robotics Co.Customer workspace · Email request

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

Reply draftPreview only · not sent

Interactive concept. No live customer data, AI request or outgoing message.

AI workspace

SAMPLE SUGGESTION

Start with the context.

Review the shipment record and draft an update. Keep any credit or refund behind approval.

Context usedOrder snapshot · sampleShipping policy · sample

Suggested reply

Thanks for flagging this. We’ll check the replacement shipment’s latest tracking update and confirm the next step before making any changes.

Sample text only. No AI call, investment decision, legal advice or outgoing message.

Interactive product concept · sample data, not a connected AI serviceAgents / Memory / Knowledge / Tools

Take the next step.

Start from source, request Cloud access, or discuss a client project.

Run the starter Request Cloud access Deliver for a client

Runtime & deployment Benchmark & methodology All products Pricing Application ideas

← 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.

Free to Build. Free to Run. LibraOS Runtime is currently available at no license cost for development and standard production use, subject to the applicable license terms. Runtime and service costs →

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
Measurement	LibraOS	Agno	LangGraph*
Idle memory · RSS	51.7 MB	142.9 MB	156.8 MB
Peak memory · 256 concurrency	463.1 MB	447.1 MB	680.6 MB
CPU per run · sequential	10.9 ms	18.55 ms	56.6 ms
Cold start → first run	2.01 s	3.44 s	3.63 s
Sequential latency · p50	9.9 ms	24.1 ms	1000.9 ms
Latency at 256 concurrency · p95	3.094 s	4.295 s	41.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 →