TL;DR

OpenSpace is an open-source “skill management layer” for AI agents. Instead of dumping skill files into a folder and hoping the agent picks the right one, OpenSpace tracks which skills actually complete real tasks, evolves them from execution evidence, and shares them across agents with quality signals attached. Key highlights:

  • From HKUDS (the University of Hong Kong Data Intelligence Lab, the group behind LightRAG and several trending agent repos), MIT-licensed, Python 3.12+
  • v2 shipped July 2026 — added a quality layer, controlled evolution, and a package-based cloud “Skill Wiki”
  • Plugs in over MCP: works with Claude Code, Codex, Cursor, OpenClaw, nanobot, or any MCP-capable host
  • Benchmark: on the same frozen backbone, a “cold” run scored 65.2% and warmed up to 78.7% as the trusted skill library evolved — with a reported ~46% reduction in token usage
  • Three evolution modes — FIX, DERIVED, CAPTURED — decide when and how a skill changes, all with version history
  • Local-first: skills run and evolve on your machine; the cloud is only for discovery and sharing

Install with pip install -e ., point it at your agent’s skill directory, and your agent gets a memory of what works. Below is a hands-on look at the architecture, real setup, community reactions, and the limitations you should know before trusting it in production.

What is OpenSpace?

Everyone building with agents in 2026 hit the same wall: skills scale badly. The “skills” pattern — a folder of SKILL.md files that teach an agent reusable procedures — was popularized by Anthropic and is now everywhere, from Claude Code to OpenClaw. It works great with ten skills. It falls apart at a few hundred.

OpenSpace is HKUDS’s answer to that scaling problem. Its own framing is blunt: when an agent performs poorly, the problem is not always the model. Sometimes the agent simply fails to retrieve the right skill, apply it to the right task, or choose the version that actually works. As your library grows, more choices make the right skill harder to find, not easier.

So OpenSpace reframes skills as something to be managed across a full lifecycle:

  • 🔍 Retrieve — find the right skill for every task
  • ✅ Evaluate — know what works through real outcomes
  • 🤝 Share — turn successful workflows into team knowledge
  • 🔄 Evolve — improve skills with every run

The pitch is “one skill library across all your agents.” Whether your agent is Claude Code, Codex, or a custom MCP host, they can all retrieve, import, and reuse skills from one shared library instead of rebuilding the same capability five times.

The core idea: quality as the signal

Most “agent memory” systems accumulate. You run a task, something gets saved, the pile grows. OpenSpace’s central bet is that accumulation without a quality signal is noise. Its v2 architecture has four connected layers, and quality is the thread running through all of them.

1. The quality layer

This layer answers one question: which skills can the agent actually trust? Rather than trusting a skill’s description, OpenSpace records what happened on real runs:

  • Skill outcomes — was a skill selected, applied, did it complete the task, or did the agent fall back to something else?
  • Tool reliability — it tracks tool failures and slowdowns that can quietly make a skill unreliable, even if the skill’s own logic is fine.
  • Task result as evidence — the judgment comes from real task behavior, not from how good the skill looks in a file.

The practical effect: your skill folder becomes easier to trust because the system knows what worked in real runs. Skills earn trust by delivering results, not by reading well.

2. Controlled skill evolution

This is the part that separates OpenSpace from a static skill registry. It answers when should a skill change? — and it uses three explicit modes:

  • FIX — repair a broken or outdated skill.
  • DERIVED — create a better or more specialized version from an existing skill.
  • CAPTURED — save one reusable sub-workflow, but only when the execution trace shows both the workflow running and a separate validation of the claimed outcome. Notably, whole-task success is “neither required nor sufficient” — OpenSpace won’t capture a workflow just because the overall task passed.

Crucially, evolution is provisional by default. New skills have to prove themselves across tasks before they’re trusted, improvements are validated before they replace a working version, and every change is version-tracked. There’s even a bounded “capture review” step that checks the authored skill doesn’t smuggle in a broader or unverified procedure than the evidence supports. This is the design detail that should make production users comfortable: skills adapt to the real world while every change stays reviewable.

3. Local-first skill hub

Your skills run locally; your data doesn’t have to leave the machine. The cloud (open-space.cloud) is for discovery — cloud skills are grouped by package so people can browse, review lineage, and inspect quality signals before importing. Import is always explicit: a cloud skill lands in your local skill folder before any reuse. As HKUDS puts it, “the cloud is for skill discovery; your machine is for agent execution — the line never blurs.”

4. Agent harness with quality records

Underneath everything is a runtime that runs the agent in a way that leaves useful evidence: recoverable long-running sessions, permission-aware and sandboxed tool calls, and quality records produced by every execution. CLI, Python API, MCP, gateway, and dashboard all share one execution model — so evidence is consistent no matter how you invoke it.

Getting started

OpenSpace is a normal Python package. The one gotcha worth knowing up front: the default clone drags in ~50 MB of demo assets, so use the sparse-checkout trick if you just want the code.

# Standard install
git clone https://github.com/HKUDS/OpenSpace.git && cd OpenSpace
pip install -e .
openspace-mcp --help   # verify installation

# Lightweight clone (skips the ~50 MB assets/ folder)
git clone --filter=blob:none --sparse https://github.com/HKUDS/OpenSpace.git
cd OpenSpace
git sparse-checkout set --no-cone '/*' '!/assets/'
pip install -e .

Path A — plug it into your agent (MCP)

For an MCP host, you register OpenSpace as an MCP server and point it at your agent’s skill directory. The stdio transport is simplest:

{
  "mcpServers": {
    "openspace": {
      "command": "openspace-mcp",
      "toolTimeout": 600,
      "env": {
        "OPENSPACE_HOST_SKILL_DIRS": "/path/to/your/agent/skills",
        "OPENSPACE_WORKSPACE": "/path/to/OpenSpace",
        "OPENSPACE_CLOUD_MODE": "live",
        "OPENSPACE_CLOUD_API_KEY": "sk-xxx"
      }
    }
  }
}

Then copy the two host skills that teach your agent when and how to use OpenSpace:

cp -r OpenSpace/openspace/host_skills/delegate-task/ /path/to/your/agent/skills/
cp -r OpenSpace/openspace/host_skills/skill-discovery/ /path/to/your/agent/skills/

That’s it — no extra prompting. For OpenClaw and nanobot, credentials (API key, model) are auto-detected from the host config; other hosts set OPENSPACE_LLM_API_KEY / OPENSPACE_MODEL. There’s also SSE and streamable-HTTP transport if you’d rather run OpenSpace as a standalone server.

Set the tool timeout to at least 600 seconds. OpenSpace’s own setup guide is explicit about this — execute_task calls can run for minutes, and a short host-side MCP timeout will kill long jobs mid-flight. This is the single most common setup mistake.

Path B — command line

You can also drive it directly, no MCP host required:

# Interactive mode
openspace

# One-shot task with an explicit model
openspace --model "anthropic/claude-sonnet-4-5" \
  --query "Create a monitoring dashboard for my Docker containers"

Project skills live under .openspace/skills/<skill-name>/, each a directory with a SKILL.md and optional helper files.

Path C — embed the Python API

If you want OpenSpace inside your own runtime rather than behind MCP or the CLI:

import asyncio
from openspace import OpenSpace
from openspace.runtime import ExecutionRequest

async def main():
    async with OpenSpace() as cs:
        result = await cs.execute(
            ExecutionRequest(
                prompt="Analyze GitHub trending repos and create a report",
            )
        )
        print(result.text)
        for skill in result.evolved_skills:
            print(f"  Evolved: {skill['name']} ({skill['origin']})")

asyncio.run(main())

Notice result.evolved_skills — after a run, OpenSpace tells you exactly which skills changed and why (FIX / DERIVED / CAPTURED). That feedback loop is the whole point.

The dashboard

There’s a local dashboard (Node.js ≥ 20) that visualizes how your skills evolve — browse skills, track lineage, and compare diffs across versions:

# Terminal 1: backend API
openspace-dashboard --port 7788

# Terminal 2: frontend dev server
cd apps/dashboard && npm install && npm run dev

For a team, this is where the “shared knowledge” story becomes tangible: you can see which skills a colleague’s agent captured, review the lineage, and decide whether to import them.

Does it actually work? The benchmark

HKUDS reports a clean cold-to-warm result: with the same frozen backbone model, an OpenSpace agent scored 65.2% on a cold run (empty skill library) and improved to 78.7% on a warm run once its trusted skill library had evolved. Independent write-ups add a second data point — a reported ~46% reduction in token usage as reusable skills replaced repeated reasoning from scratch.

The mechanism is intuitive: the first time an agent solves a class of task, it burns tokens reasoning it out. OpenSpace captures the validated sub-workflow, and the next time a similar task arrives, the agent retrieves a proven skill instead of re-deriving it. Cheaper, faster, and more consistent — if the retrieval and quality gates work as advertised.

The honest caveat: this is a single-lab benchmark on “50+ real professional tasks,” not a broad public leaderboard. Treat 65→79% as a promising internal signal, not a settled fact.

Community reactions

OpenSpace hit #1 on GitHub Trending after open-sourcing in late March 2026, and coverage has been steady. MarkTechPost published a hands-on implementation walkthrough highlighting the cold-to-warm transition. A Medium roundup of self-evolving agents singled out the FIX/DERIVED/CAPTURED model and the 46% token reduction as the differentiators from plain “agent memory.”

The most useful outside voice is more measured. Starlog’s review put it plainly: “OpenSpace has quality gates and sandboxing, but the system is immature. A malicious or poorly written skill could leak data, consume excessive resources, or break your agent’s reliability.” That’s the right frame — the design is thoughtful, but the surface area (arbitrary skills executing with tool access) is inherently risky.

To HKUDS’s credit, they’ve clearly been thinking about this. The changelog shows repeated security work: hardened zip extraction and import_skill against path traversal, a check_skill_safety gate that blocks skills with prompt-injection or credential-exfiltration patterns before loading, and a pin of litellm <1.82.7 to dodge a real supply-chain advisory (PYSEC-2026-2). The scaffolding is there; it just hasn’t been battle-tested at scale yet.

Honest limitations

Nothing here is a dealbreaker, but go in with eyes open:

  • Security surface is real. You’re running community-authored skills with tool access. check_skill_safety and sandboxing help, but a determined bad skill is a genuine risk. Only import cloud skills you’d review yourself, and keep the sandbox on.
  • Immature. This is a months-old v2 from an academic lab. Expect rough edges — the changelog is full of Windows fixes, stdio deadlocks, and MCP timeout tweaks that landed recently.
  • Python 3.12+ and a real setup. This isn’t a one-line add-on. You need the right interpreter, correct MCP registration, a 600s+ timeout, and (for the dashboard) Node 20+. Getting all of it right the first time is fiddly.
  • The benchmark is self-reported. 65→79% is encouraging but from one lab on its own task set. There’s no independent leaderboard yet.
  • Cloud is optional but incomplete. All local capabilities work without cloud access, but the “shared team knowledge” story depends on the cloud community, which is still young.
  • Quality signals need volume. The whole value proposition — trusting skills by outcomes — only kicks in after your agent has run enough tasks to generate evidence. On day one, you get a normal skill folder.

Who should use it?

Good fit: developers and teams running an agent on recurring, repeatable work — the kind where the same class of task shows up weekly and re-deriving the solution every time is wasteful. If you already lean on the skills pattern in Claude Code or OpenClaw and your skill folder is getting unwieldy, OpenSpace is the natural next layer.

Not yet: anyone who needs a locked-down, audited, production-hardened system today, or who wants zero setup. The security surface and the “immature v2” reality mean this is best treated as a powerful tool for people who’ll review what it imports and monitor what it evolves.

FAQ

Is OpenSpace free and open source? Yes — MIT-licensed and fully open source on GitHub. All local capabilities (task execution, skill evolution, local search) work without any cloud account or API key beyond your own LLM provider key.

Which agents does OpenSpace work with? Any MCP-capable host. It ships helpers for OpenClaw and nanobot and can be wired manually into Claude Code, Codex, Cursor, or others. It also runs standalone via its own CLI or Python API.

What’s the difference between OpenSpace v1 and v2? v1 gave agents a persistent skill memory that learned from tasks and shared experience. v2 (July 2026) added the missing management and quality layer — skills are continuously evaluated against real outcomes, evolved only when evidence demands it, and shared with quality context instead of being uploaded and forgotten.

Is it safe to import community skills? With caution. OpenSpace runs check_skill_safety to block prompt-injection and credential-exfiltration patterns, hardens imports against path traversal, and sandboxes tool calls. But running third-party skills with tool access is inherently risky — only import skills you’d review yourself, and keep sandboxing enabled.

Do I need the cloud community? No. The cloud is purely for skill discovery and sharing. Local task execution, skill search, and evolution all work offline. The cloud just lets you browse and import proven skills from others.

What does the 65.2% → 78.7% benchmark mean? It’s HKUDS’s own measurement: the same frozen model scored 65.2% with an empty skill library (cold) and 78.7% after its skill library had evolved through real tasks (warm), alongside a reported ~46% token reduction. It’s a promising internal signal, not an independent public benchmark.

Bottom line

OpenSpace is the most thoughtful answer yet to a problem every serious agent builder now has: skills scale badly without a quality signal. The four-layer design — quality, controlled evolution, local-first sharing, and an evidence-producing harness — is genuinely well-considered, and the FIX/DERIVED/CAPTURED evolution model with provisional-by-default trust is the kind of design detail that suggests the authors actually shipped agents in anger.

The cold-to-warm benchmark and token savings are real, if self-reported. The security surface and v2 immaturity are also real. If you run agents on recurring work and you’re willing to review what you import and monitor what you evolve, OpenSpace turns your skill folder from a pile into a memory. That’s a meaningful upgrade — just don’t mistake “well-designed” for “battle-tested” yet.

Repo: github.com/HKUDS/OpenSpace · Explore skills: open-space.cloud