The Dakera Playground Is Live — Try Agent Memory in Your Browser

Most developer tools have a demo. Dakera has a playground — because the only honest benchmark for memory infrastructure is what it does with your data, against a real engine, right now. Open the playground and in under thirty seconds you'll be storing memories, recalling them with sub-60ms latency, and watching the importance scorer rank your results. No account, no Docker, no API key. Just the real thing.

Why a playground?

When developers first encounter Dakera, the most common question is: "What does hybrid retrieval actually feel like at this latency?" A README answers it in theory. The playground answers it in practice.

Every request in the playground goes to a real Dakera instance — the same engine that runs in production, the same ONNX embedding models, the same HNSW index. There's no mock API, no pre-recorded responses, no sleight of hand. When you store a memory, it's stored. When you recall it, the engine runs the full retrieval pipeline: embed your query, traverse the vector index, run BM25 full-text scoring, merge and rerank by importance. You see the actual result, including the importance score the engine computed.

Five scenarios, one complete picture

The playground is organized around five scenarios, each targeting a distinct capability of the Dakera memory model. Work through them in order and you'll have covered the full API surface in under ten minutes.

Sandbox limits — and why they're the right defaults

The playground runs in a sandboxed environment designed to let you explore safely. Each browser session gets its own isolated namespace on the engine — your memories don't mix with anyone else's. Sandbox limits are set to be generous enough for meaningful exploration while protecting the shared infrastructure:

When your session expires, all data is automatically deleted. Nothing persists between playground sessions — which also means you can explore freely without worrying about leaving test data behind.

SDK quickstarts in four languages

Once you've run the scenarios, the playground surfaces the equivalent SDK code for each operation in your language of choice. Copy it into your project and you're storing your first real memory in under a minute.

The SDK examples use the same operations you ran in the playground, against your own self-hosted Dakera instance. Swap in your endpoint and API key, and the code runs unchanged.

# Python — the same recall you ran in the playground
from dakera import AsyncDakeraClient
import asyncio

async def main():
    client = AsyncDakeraClient(
        url="http://localhost:3300",
        api_key="your-key"
    )

    # Store memory with importance
    mem = await client.memories.store(
        agent_id="my-agent",
        content="User prefers async Python patterns and type hints",
        importance=0.85
    )

    # Hybrid recall — same engine as the playground
    results = await client.memories.recall(
        agent_id="my-agent",
        query="coding preferences",
        top_k=5
    )

asyncio.run(main())

From playground to production

You just ran the same memory engine that production Dakera instances use — hybrid retrieval at 88.2% LoCoMo recall accuracy, real importance scoring, real vector search. That's not a simulation. It's the actual system.

The path from playground to production is shorter than you'd expect. There are three ways to go further, in order of time-to-value:

The playground stays open. Come back to prototype a retrieval pattern, test a query, or benchmark latency before deploying a change. It's a live API, not a snapshot — every request you make in the playground is real.