superlocalmemory

SuperLocalMemory V4.1.14

Rent the LLM. Own the memory.

Rent an LLM — but own the memory, for your company and for your industry.

The governed memory layer for AI agents: local-first, auditable, and built for the compliance obligations teams now actually carry.

Models are interchangeable and rented by the token. What your agents remember is

yours — it is your customers' data, your retention obligations, and your audit trail. SLM

keeps that layer on infrastructure you control, with multi-workspace isolation, role-based

access, and GDPR + EU AI Act governance controls built in.

The boundary. SuperLocalMemory starts with a local runtime;

provider-backed enrichment, cloud backup, connectors, and proxy use are explicit choices.

Different products solve different boundaries. Published benchmark evidence carried into V4

comes from the published V3 research architecture; it is not a claim of a newly rerun V4 package benchmark.

How to check that, rather than believe it. Every reliability

guarantee here is stated as a falsifiable invariant, tested under an adversarial condition with a

negative control, and shipped with the harness that regenerates the evidence:

python benchmark/run_all.py --trials 200 --output-dir results/. What each experiment

does not exercise is stated too.

v4.1.14 — one control plane: SLM-Mesh peer coordination · multi-scope memory (personal / shared / global) · profiles · Cache · Compress · 7-layer retrieval · code graph · Entity Explorer · skill evolution · Modes A/B/C · GDPR retention & audit chain · bounded loops — across CLI, MCP, dashboard, the Claude plugin, the Codex add-on, and documented IDE integrations.

Proxy: slm wrap claude  ·  MCP: add slm_compress to your config  ·  Skill: zero-config

Four public arXiv preprints · V4: · companion archive: () · prior preprints: · · .

Why SuperLocalMemory?

SuperLocalMemory is an enterprise-grade, local-first memory control plane for AI agents. Your team's agent memory lives on infrastructure you control, with per-workspace isolation, role-based access, and GDPR / EU AI Act governance controls — built for organizations, and for EU data-residency obligations where agent context must not leave your environment by default.

Agent-memory systems make different storage, model-provider, and deployment trade-offs. SuperLocalMemory starts with a local runtime and makes provider-backed enrichment, cloud backup, connectors, and proxy use explicit choices.

Different products solve different boundaries. The published LoCoMo benchmark evidence in this README is protocol-scoped evidence from the published V3 research architecture; it is carried forward for continuity and is not a claim of a newly rerun V4 package benchmark.

SuperLocalMemory V4 combines conventional dense and lexical retrieval with graph, temporal, associative, and statistical relevance scoring in a 7-layer control plane (admission → queryable core → enrichment → brain → multi-channel retrieval → context safety → operations). The default local runtime does not require Docker, a separately operated graph database, or an API key.

Memory with a sense of time. SLM does not only store *what* an agent learned — it records *when*. Every fact carries ingestion timing and provenance; recall runs a dedicated temporal candidate channel alongside semantic, lexical, and associative retrieval; scenes and entity timelines reconstruct sequence; and the lifecycle lets neglected memory decay and self-archive instead of growing without bound. Time is a first-class ranking and lifecycle signal rather than a timestamp column an agent never reads — which is what lets a long-lived agent reason about how its context changed, not only what it currently holds.

What changed in this release. See the CHANGELOG — every release is written up there, in plain language, newest first.

• **SLM-Mesh** — authenticated cross-session and cross-machine peer coordination (messages, locks, shared state, inbox/outbox, optional discovery). Coordination only — not automatic replicated memory.
• Multi-scope memory & profiles — workspaces (profiles) plus `personal` / `shared` / `global` scopes; cross-profile recall is default-deny.
• Cache & compression (context optimization) — exact-match cache with tagged invalidation, safe compression, and opt-in reversible/aggressive paths across proxy, MCP, and skill surfaces.
• Entity Explorer & skill evolution — compiled entity summaries/timelines; opt-in skill lineage, budgets, and verification outcomes.
• Modes A / B / C — local-only (A), on-device LLM enrichment (B), provider-assisted (C). An operating mode records technical locality facts; it does not determine EU AI Act legal compliance (that is deployment-context assessment — see Privacy controls).
• GDPR posture, retention & audit chain — export, fail-closed cross-store erasure, retention policies, and a hash-chained audit trail. Engineering controls for compliance programs, not a legal certification.
• 7-layer retrieval/recall stack & code graph — multi-channel candidates (semantic, BM25, temporal, Hopfield, spreading activation) plus optional code-graph tools for blast radius and review context.
• MCP profiles — `code` exposes 31 tools for installed coding agents; `full` 49; `power` 61; `whole` 94 (all registered). Also `core` (16), `mesh` (8), and the unrestricted default surface (49 with mesh enabled).
• Governed write path & verifiable transactions — admission + policy control, a per-owner obligation ledger, and a hash-sealed completion manifest with a reconciler that redrives unmet obligations.
• Self-healing lifecycle & admin remediation — stale locks cleared on restart; list/resolve stuck operations from CLI, MCP, or the dashboard.

SLM is one strand of Qualixar's work on AI reliability engineering: making agent behavior observable, bounded, and reproducible instead of best-effort.

The architecture evaluated in the V3 paper remains the foundation of this release. The figures below keep their original LoCoMo protocol, answer-construction, model, and sample scope.

How SLM fits beside other memory systems

Different products solve different boundaries. SLM is for developers who want

one local-first operating control plane—not only an SDK, managed context API,

or agent runtime. It combines dated evidence, graph-aware retrieval, cache and

compression controls, SLM-Mesh, and MCP/CLI/hooks/dashboard/IDE

surfaces in one install.

See the source-linked market comparison

for current primary sources and protocol-scoped benchmark evidence. A LoCoMo

percentage is comparable only when the dataset scope, answer model, judge,

retrieval stack, and release artifact match.

The V4 capability architecture

SuperLocalMemory is one local control plane for persistent agent context. It is

not just a vector store: the same runtime can accept evidence, build and govern

memory, retrieve bounded evidence for an agent, and expose cache, compression,

and SLM-Mesh peer-coordination controls through a CLI, MCP, dashboard, and supported

IDE integrations.

*Architecture boundary: SQLite + sqlite-vec remain canonical; CozoDB and

LanceDB are parity-gated projections; SLM-Mesh coordinates trusted peers rather

than replicating a distributed memory database; connectors are opt-in.*

Memory boundaries: profiles isolate workspaces by default. Every memory is

`personal`, `shared` with named profile readers, or `global`; cross-profile

recall is default-deny and must be explicitly enabled. This scoped sharing is

local authorization, not SLM-Mesh synchronization. See

shared-memory.md.

IDEs, agents, scripts, connectors, and humans
             │  CLI · MCP (HTTP/stdio) · hooks · dashboard
             ▼
 ┌────────────────────────── SLM CONTROL PLANE ──────────────────────────┐
 │  1. Admission       identity, scope, idempotency, raw evidence         │
 │  2. Queryable core  SQLite facts + FTS durable receipt                  │
 │  3. Enrichment      facts, entities, scenes, time, provenance, graph   │
 │  4. Memory brain    feedback, patterns, rewards, consolidation          │
 │  5. Retrieval       semantic · BM25 · temporal · Hopfield · activation │
 │  6. Context safety  policy, trust, provenance, redaction, budgets      │
 │  7. Operations      lifecycle, audit, cache/compress, mesh, backups    │
 └───────────────────────────────────────────────────────────────────────┘
             │
             ▼
 SQLite + sqlite-vec canonical store  ──► optional graph/vector projections

The seven stages are an execution model, not a promise that every optional

enricher or retrieval channel runs for every request. The receipt, trace, and

health surfaces expose the stages actually completed by the installed runtime.

What the dashboard exposes

`slm dashboard` opens a local operational view of the same control plane:

Dashboard visibility is not a substitute for runtime proof: use `slm doctor`,

`slm health`, `slm trace`, and the relevant CLI/MCP operation to validate a

deployment.

Watch the product walkthrough

**Watch the SuperLocalMemory demo on YouTube** — a five-minute walkthrough of installation, setup, recall, cache, and compression. The video shows a product walkthrough; use the commands and release notes in this README as the current release contract.

Published LoCoMo evidence (V3 architecture, carried into V4)

The V3 paper evaluates the multi-channel architecture that V4 still runs. Every figure below

is protocol-scoped, so a reader can distinguish local retrieval, answer

construction, and cloud-assisted evaluation rather than treating unlike runs as

one score.

Published category results: Mode A Retrieval scored 72.0% single-hop,

70.3% multi-hop, 80.0% temporal, and 85.0% open-domain. Mode C

scored 64.0% single-hop, 100.0% multi-hop, and 86.0% open-domain

on its 81-question Conv-30 scope (no temporal category was reported for that

run). Across six LoCoMo conversations, the paper reports 71.7% with the

information-geometric layers versus 58.9% without them: +12.7pp.

See arXiv:2603.14588 and the [official

LoCoMo paper](https://arxiv.org/abs/2402.17753) for the full protocol,

ablation table, and limitations. These are published V3 architecture results

carried into V4—not a substitute for a newly rerun release-artifact benchmark.

Quick Start

# Primary path 1 — npm global CLI (Node 18+)
# Creates a package-owned virtual environment. It does not modify system Python.
npm install -g superlocalmemory
slm setup       # Choose mode (A/B/C)
slm doctor      # Verify everything is working

# Primary path 2 — Python CLI + SDK in an activated virtual environment
python3 -m venv .venv
source .venv/bin/activate  # Windows PowerShell: .venv\Scripts\Activate.ps1
python -m pip install superlocalmemory
slm setup
slm doctor

# First use
slm remember "Alice works at Google as a Staff Engineer" --json
slm recall "What does Alice do?"
slm status

The default daemon write commits raw evidence plus a relational/FTS projection

and returns a durable receipt in `queryable` state. Enrichment then advances the

same operation through `enriching` to `complete`, or records a retryable

`failed` state. Use `slm remember "..." --sync` when the caller must wait for

all declared derivation and projector stages. JSON output includes the opaque

`operation_id`, current `materialization_state`, and fact IDs.

# Wrap your agent — starts proxy + sets environment + launches agent
slm wrap claude
# Your first repeat prompt → CACHE HIT → $0.00
# See savings: slm optimize savings --since 1

Upgrading: use the owner of the installation: `npm update -g superlocalmemory`

or, while the Python virtual environment is active,

`python -m pip install --upgrade superlocalmemory`. Then run

`slm restart && slm doctor`. Repository-clone users use the matching `upgrade`

action in `scripts/install.sh` or `scripts/install.ps1`. Installers never move

or delete memory data.

Three Pillars

Memory

Current recall has five candidate producers—dense semantic, BM25 lexical,

temporal, Hopfield associative, and spreading activation—followed by fusion,

optional reranking, and entity-graph score enhancement. The entity graph does

not create an independent candidate in the current implementation. Core memory

is SQLite-backed. SQLite and sqlite-vec remain the canonical source of truth.

The packaged Scale Engine can maintain CozoDB graph and LanceDB vector

projections, and it remains outside active retrieval paths until a staged

parity witness proves it matches the canonical store. New installations remain

on Local Core. During upgrade, `slm db scale status` can identify a positive

pre-v3.7 layout candidate; the operator confirms it with `slm db scale adopt`.

SLM then rebuilds from canonical SQLite, verifies it, and promotes it with a

durable recovery journal while retaining the prior directories as a rollback

backup. `adopt` reports `restart_required: true`; run `slm restart` before

checking daemon health. If proof fails, recall remains on SQLite and status

retains the rejected manifest for inspection, retires its replaceable derived

payload, and allows a corrected retry.

Canonical ingestion is a durable state machine: `raw → queryable → enriching →

complete`, with `failed` retaining raw evidence, error details, attempt count,

and retry timing. SQLite relational facts and FTS are the queryable checkpoint;

optional ANN/vector projectors are verified before `complete` is granted.

Recalled text is treated as untrusted evidence. Hooks, MCP `session_init`, CLI

session context, and chat use one bounded renderer that redacts recognized

secrets, neutralizes forged boundary markers, and attaches provenance. Trusted

IDE instruction files contain only the static SLM protocol; fresh memory is

retrieved at runtime rather than copied into those files.

Score Contract v2: `relevance_score` is query-relative relevance;

`ranking_score` is internal ranking utility; `memory_confidence` belongs to the

stored assertion; and `trust_score` is an evidence-policy signal. Legacy

`score` and `confidence` remain aliases for one compatibility release. It is

explicitly uncalibrated: `calibration_status` is `uncalibrated` and

`answer_confidence` is `null`. See

the retrieval score contract.

The retrieval/lifecycle implementation includes three mathematical layers that

can run without a cloud LLM:

1. Fisher-informed scoring — dense candidate generation uses cosine similarity; Fisher-derived terms can modify later scoring when their state is available.

2. Sheaf Cohomology for Consistency — algebraic topology detects contradictions via coboundary norms on the knowledge graph.

3. Riemannian Langevin Lifecycle — memory positions evolve continuously on the Poincare ball, and where a memory sits decides its lifecycle stage. There is no retention timer counting down against a memory: what moves it outward is being left alone, and what pulls it back is being used. The stage boundaries themselves are fixed radii.

Auto-capture hooks are installed explicitly with `slm hooks install` (Claude

Code) or `slm hooks install --agent codex` (Codex). Hook latency and capture

quality must be evaluated for the target client and workload; SLM publishes no universal p99 claim.

Multi-scope memory (opt-in): keep memories `personal` (default), `shared` with named profiles, or `global` across the machine. Off by default — recall only ever returns your own facts until you turn sharing on, per call or in config. See **docs/shared-memory.md**.

Multilingual models: configure an OpenAI-compatible embedding endpoint such as Ollama, vLLM, LiteLLM, `bge-m3`, `multilingual-e5`, or `Qwen3-Embedding`. Language coverage and retrieval quality depend on the selected model and should be evaluated for the deployment corpus.

Cache + Compress

One engine, three ways in — choose the surface that fits your setup:

The hard constraint: The primary Claude conversation turn cannot be cached without a proxy. The MCP/skill path caches results you explicitly route through SLM (tool outputs, file reads, sub-model calls) — without a proxy the main conversation turn is not intercepted.

How to choose:

• Metered API (pay-per-token), want every call cached → Proxy (A)
• Pro/Max/Team subscription or any plan where you won't run a proxy → MCP tools (B) or Skill (C)
• Zero configuration → Skill (C): install once, auto-compresses CLAUDE.md and large outputs
• Agent-controlled caching of repeated file reads → MCP tools (B)

Cache: exact-match SQLite lookup is the stable cache path. Semantic cache

controls are experimental until release-linked precision, invalidation, and

tenant-isolation evidence exists. A cache hit can avoid a provider request, but

actual cost and latency savings depend on the intercepted surface and provider.

Compress: safe mode uses conservative normalization and preserves JSON and code; measured reduction varies by content and can be zero. Aggressive prose compression is opt-in and lossy. CCR can retain an original for later byte-exact retrieval when reversible storage is enabled.

Savings dashboard: `slm optimize savings --since 7` — live USD/INR/tokens saved. Hot-reload config, fail-open.

SLM-Mesh (cross-session / cross-machine coordination)

SLM-Mesh is the V4 peer-coordination plane: authenticated messages, locks, shared lightweight state, inbox/outbox, and an offline queue between configured peers (same machine sessions or cross-machine). Optional mDNS discovery (`SLM_MESH_DISCOVERY=on`). It is not a replicated or conflict-resolving distributed-memory database — multi-scope memory sharing is a separate local-authorization feature.

# Machine A (broker)
export SLM_MESH_HOST=192.168.1.100
export SLM_MESH_SHARED_SECRET=my-secret-key
slm init

# Machine B (client)
export SLM_MESH_PEER_URL=http://192.168.1.100:8765
export SLM_MESH_SHARED_SECRET=my-secret-key
slm init

Eight SLM-Mesh MCP tools: `mesh_summary`, `mesh_peers`, `mesh_send`, `mesh_inbox`, `mesh_state`, `mesh_lock`, `mesh_events`, `mesh_status`.

Full docs: docs/multi-machine.md · docs/distributed-deployment.md

Install Paths

> V4 platform support: Apple Silicon macOS, 64-bit Windows, and 64-bit Linux. Intel Mac and 32-bit Windows are not supported by the patched `cryptography` 50 runtime.

After any install path: `slm setup` → `slm doctor` → `slm warmup` (optional, pre-downloads ~500MB embedding model).

Upgrading an existing installation

An npm, pip, or repository update upgrades the SLM runtime; it does not silently

rewrite your IDE configuration, hooks, or plugin state. Review the existing

integrations first:

slm upgrade-hosts

Then explicitly apply the hosts you approve, for example

`slm upgrade-hosts --host codex --apply`, or use

`slm upgrade-hosts --all-detected --apply` after reviewing the preview. See

Host Integration Upgrades for the full safety contract

and the Claude Code plugin update path.

MCP + Profiles

SLM supports two MCP transports:

HTTP (recommended):

{ "mcpServers": { "superlocalmemory": { "type": "http", "url": "http://127.0.0.1:8765/mcp/" } } }

Or: `claude mcp add --transport http superlocalmemory http://127.0.0.1:8765/mcp/`

stdio (universal fallback):

{ "mcpServers": { "superlocalmemory": { "command": "slm", "args": ["mcp"] } } }

MCP Profiles

Control tool surface via `SLM_MCP_PROFILE`:

Precedence: `ALL` > `TOOLS` > `PROFILE` > `default`

export SLM_MCP_PROFILE=full   # or core / code / mesh / power / whole
slm mcp

For a predictable small surface, set `core` explicitly. Leaving the variable

unset retains the compatibility default, whose mesh tools follow the local

mesh setting. Count-suffixed aliases remain for backward compatibility and emit a migration warning: `core14`, `core16`, `code20`, `code21`, `code24`, `code28`, `code29`, `code31`, `mesh8`, `full38`, `full39`, `full42`, `full46`, `full47`, `full49`, `power50`, `power51`, `power54`, `power58`, `power59`, `power61`, `whole81`, `whole84`, `whole91`, `whole92`, `whole94`. Unknown names stop startup instead of silently selecting another tool set.

Per-IDE configs available for Claude Code, Cursor, Windsurf, VS Code Copilot, Continue, Gemini CLI, JetBrains, Zed, and more (15 configs in `ide/configs/`). See docs/ide-setup.md.

Editor plugins

The plugin is how most people should install SLM. It brings the MCP server, the

skills, the sub-agents, the slash commands and the hooks in one step, and keeps

them at the same version as the package.

Five surfaces, one source. Everything below is generated from `plugin-src/`,

so no surface can quietly fall behind another:

What you get

• Skills — `slm-remember`, `slm-recall`, `slm-session`, `slm-graph`,

`slm-mesh`, `slm-scope`, `slm-profile`, `slm-governance`, `slm-cache`,

`slm-compress`, `slm-status`, `slm-loop`.

• Sub-agents — a memory advisor, a governance advisor, a context-optimization

advisor, and a loop runner, each scoped to the tools it actually needs.

• Commands — `/slm-loop`, to run a task as a gate-verified bounded loop.
• Hooks — session start and end, so context loads and commits without being

asked.

Hermes

Hermes users get the same SLM skills and advisor roles through a native

`plugin.yaml` package, plus `/slm ` and generated `/slm-`

aliases for the public CLI surface. The plugin is intentionally separate from

the PyPI/npm runtime: install the owning SLM runtime first, then install the

reviewed pinned pack from the `v4.1.13` GitHub release. It is additive and does

not replace Hermes's selected memory provider or existing configuration. See

the Hermes integration guide.

Keeping it current

`pipx upgrade superlocalmemory` upgrades the package. It does not

upgrade the plugin — those are separate channels, and the plugin is delivered by

your editor. `slm doctor` reports both versions side by side and names the

command that updates the one that is behind.

claude plugin marketplace update qualixar
claude plugin update superlocalmemory@qualixar

For the other three, replace the directory from the tag you are on.

Privacy controls and operating modes

slm mode a   # Zero-cloud (default)
slm mode b   # Local Ollama
slm mode c   # Cloud LLM

Mode A can run core memory operations without sending memory content to a cloud model provider. This does not disable optional connectors, cloud backup, proxy providers, dependency acquisition, or model downloads; review configuration and network policy for the deployment.

SuperLocalMemory provides local storage, export/erasure commands, provenance, policy, and audit features that can support a compliance program. The software is not a legal certification, and compliance depends on the use case, operator, configuration, and surrounding systems.

Available controls include local export and erasure commands, hash-chained audit records, provenance tracking, and ABAC policy enforcement. Verify their behavior and retention boundaries for your deployment; see docs/compliance.md.

Teams and Enterprise Memory (V4)

V4 includes multi-user, multi-workspace controls for teams and organizations (introduced on the 3.8 line and retained). These are opt-in — personal single-user installs work exactly as before with no required login.

Users and roles

SLM supports three role tiers within a workspace: admin, member, and viewer.

Roles are scoped per workspace (profile). A user may have different roles in different workspaces.

Workspace isolation

Each workspace (profile) is a fully isolated memory namespace. One workspace cannot read another's personal memories. Shared and global scopes are opt-in and still profile-bounded at the authorization layer.

Login gate

Enterprise deployments set `require_login = true` in configuration. With login enabled:

• Every dashboard and API request requires an authenticated session.
• First-run creates an admin account with a user-chosen password (no default credentials are shipped).
• Session cookies use `HttpOnly` with optional `Secure` enforcement.
• Personal installs run with `require_login = false` (loopback owner is trusted).

slm config set security.require_login true   # Enable for team/enterprise use

Memory scopes

Recall is default-deny: shared and global facts are never returned unless the caller explicitly opts in (`--include-shared`, `--include-global`) or the scope policy allows it. See docs/shared-memory.md.

GDPR and data governance

SLM ships built-in controls that support GDPR compliance programs:

• Export — full profile data export as a structured JSONL bundle
• Erasure — profile deletion removes data from 30+ scoped tables; erasure is logged to the tamper-proof audit chain before any data is deleted
• Retention rules — time-based policies (`indefinite`, `gdpr-30d`, `hipaa-7y`, `custom`) applied per profile
• Audit trail — every store, recall, mutation, and erasure produces a hash-chained audit record
• PII redaction — configurable automatic redaction before memory content crosses trust boundaries

These are engineering controls. Compliance depends on deployment configuration, use case, and operator responsibility. See docs/compliance.md.

EU AI Act mode verification

SLM includes a per-mode EU AI Act *technical posture* report (`EUAIActChecker`). It records facts the runtime can know — whether data is configured to stay local, whether generative AI is used, and that transparency / human-oversight need deployment evidence.

An operating mode does not establish legal compliance under the EU AI Act. Legal risk classification and conformity assessment depend on intended purpose, affected persons, sector, deployment context, and operator controls. The checker therefore returns `compliant=None` / risk category `undetermined` for every mode and always requires deployment-context review. Mode A/B/C only change technical locality and enrichment options (for example Mode C may send content to a configured provider). See docs/compliance.md and `src/superlocalmemory/core/modes.py`.

Deployment tiers

SLM ships one binary and is configured for the appropriate tier at install or post-install time.

The installer or `slm reconfigure` sets the tier. Each setting is independently overridable at runtime. Full tier documentation: docs/deployment-tiers.md.

RBAC and teams docs

Full reference: docs/rbac-teams.md · docs/deployment-tiers.md

Bounded Loops (V4)

A bounded loop terminates only when an independent gate passes — a test

suite exit code, a linter, a JSON-schema check, or an SLM-recall condition.

The agent's own "I finished" message is recorded as advisory context and never

used as the termination signal. Every lap is persisted to SLM memory under the

tag `loop:`, so runs are auditable and resumable across sessions.

Three surfaces ship together:

# Run the built-in convergence demo (no API key needed)
slm loop demo

# Inspect recorded runs
slm loop history --name convergence-demo
slm loop show

Loop laps are stored as ordinary SLM memories and are visible in the dashboard

under Knowledge Graph and Memories (filter by tag `loop:`) and in the

Multi-Agent Memory workspace.

Framework Adapters (V4)

SLM ships nine adapters under `ide/integrations/`: LangGraph, Semantic Kernel,

Microsoft Agent Framework, LangChain, LlamaIndex, CrewAI, AutoGen, Google ADK,

and OpenAI Agents. Each wires SLM as memory and history without replacing the

framework runtime; its directory contains installation/configuration guidance.

Pydantic AI is not included because it does not expose a formal external-memory

interface.

Advanced

Open the web dashboard with `slm dashboard`; workspaces appear only when their

runtime capability is enabled and healthy. See CHANGELOG.md for

the complete release history.

Research Papers

SuperLocalMemory has a V4 arXiv preprint with Zenodo archive and DOI, plus The Living Brain (V3.3), Information-Geometric Foundations (V3), and Trust & Behavioral Foundations (V2).

Use the citation metadata on the linked arXiv or Zenodo records.

Support / License / Qualixar

See CONTRIBUTING.md, the Wiki, and LICENSE (AGPL-3.0). For commercial licensing, see COMMERCIAL-LICENSE.md or contact varun.pratap.bhardwaj@gmail.com.

Copyright (c) 2026 Varun Pratap Bhardwaj / Qualixar · Qualixar · research archive. Acknowledgments: Everything Claude Code informed skill observation; HKUDS/OpenSpace informed skill-evolution verification.

Star This Project

If this project solves a real problem for you, please star the repo — it helps other developers discover Qualixar and signals that the AI agent reliability community is growing.