Moss

A sub-10 ms semantic search runtime that embeds in your app for browser, edge, on-device, and cloud AI retrieval.

Source repo
usemoss/moss
Stars
★ 682
Last updated
2d ago
License
BSD-2-Clause
Primary language
Python

At a glance

How it runs
Library / SDK
Works with
Portable with changes
Cost
Free tier plus a paid hosted plan
Setup effort
Low · running in minutes
You'll need
Python 3.10+Node.js 20+Shell / CLINetwork accessLocal filesystem
Typical use
Developers building voice customer-support agents where retrieval latency above a few milliseconds makes conversation feel laggy.
Not a fit if
  • Teams that can't have indexes hosted on Moss Cloud
  • Fully offline or air-gapped environments

What does this agent do, and when should you use it?

Moss is a retrieval runtime that runs search and embedding inside your own process instead of calling a remote vector database. It has three parts: Moss Cloud handles ingestion, embedding, storage, and distribution; an Index packages your documents and their vectors as a single artifact; and the Runtime is embedded in your application, pulls indexes over HTTPS, holds them in memory, and serves queries locally. SDKs expose create_index, load_index, and query, with hybrid semantic plus keyword retrieval, built-in embedding models, metadata filtering ($eq, $and, $in, $near), and a WebAssembly build (@moss-dev/moss-web) that runs entirely client-side. The project's benchmark on 100,000 documents reports 3.1 ms P50 end-to-end latency, versus hundreds of milliseconds for remote vector databases. The repository also ships a CLI, database connectors, and integrations for LangChain, LlamaIndex, Pipecat, LiveKit, Vapi, ElevenLabs and more, under BSD-2-Clause.

The end-to-end flow starts at moss.dev, where you sign up for a project_id and project_key. You then call MossClient.create_index with documents that carry an id and text; Moss Cloud generates embeddings and packages them into a distributable index. Calling load_index pulls that index over HTTPS into local memory, and query performs embedding plus search inside the same process, returning a docs list together with time_taken_ms. Queries accept QueryOptions(top_k=...) or { topK } to control result count, and metadata operators filter results. For browser use, @moss-dev/moss-web is a separate WebAssembly build that downloads the index and answers queries client-side with no server. The repository additionally contains the moss-cli package for terminal index management, moss-data-connector for ingesting from SQLite, MongoDB, MySQL and Supabase, and runnable examples and apps covering multiple languages, voice agents, and framework cookbooks.

  1. Developers building voice customer-support agents where retrieval latency above a few milliseconds makes conversation feel laggy.
  2. Backend teams assembling a RAG stack who would rather embed the runtime than operate a vector database cluster.
  3. Frontend teams building static sites or browser extensions that need client-side semantic search via the WebAssembly SDK.
  4. Teams already on LangChain, LlamaIndex, DSPy, or CrewAI who want to swap in a lower-latency retriever.
  5. Builders of Pipecat, LiveKit, Vapi, or ElevenLabs voice pipelines that need retrieval inside a real-time audio loop.
  6. Teams syncing existing SQLite, MongoDB, MySQL, or Supabase data who want a ready ingestion connector.

How do you install or deploy this agent?

Server-side, install the SDK for your language and register at moss.dev for a project_id and project_key. Python requires 3.10+:

pip install moss

TypeScript / Node.js requires 20+:

npm install @moss-dev/moss

For the browser, use the separate WebAssembly package:

npm install @moss-dev/moss-web

To run a bundled example, copy the env template and fill in your credentials:

cd examples/python
pip install -r requirements.txt
cp ../../.env.example .env
python load_and_query_sample.py

How do you use this agent?

End-to-end Python usage:

from moss import MossClient, QueryOptions

client = MossClient("your_project_id", "your_project_key")

await client.create_index("support-docs", [
    {"id": "1", "text": "Refunds are processed within 3-5 business days."},
    {"id": "2", "text": "You can track your order on the dashboard."},
    {"id": "3", "text": "We offer 24/7 live chat support."},
])

await client.load_index("support-docs")
results = await client.query("support-docs", "how long do refunds take?", QueryOptions(top_k=3))

End-to-end TypeScript usage:

import { MossClient } from "@moss-dev/moss";

const client = new MossClient("your_project_id", "your_project_key");

await client.createIndex("support-docs", [
  { id: "1", text: "Refunds are processed within 3-5 business days." },
  { id: "2", text: "You can track your order on the dashboard." },
  { id: "3", text: "We offer 24/7 live chat support." },
]);

await client.loadIndex("support-docs");
const results = await client.query("support-docs", "how long do refunds take?", { topK: 3 });

What are this agent's strengths and limitations?

Pros
  • Queries execute inside your process; the published benchmark reports 3.1 ms P50 on 100,000 documents, two orders of magnitude below remote vector databases
  • Built-in embedding models mean no external embedding API key is required, with a bring-your-own-embedding path as well
  • Two runtime targets: server-side SDKs plus a WebAssembly browser build for fully client-side search
  • SDKs for Python, TypeScript, Elixir, and C, plus a CLI, database connectors, and many framework and voice-agent example apps
  • BSD-2-Clause licensed with SDKs, examples, and integrations fully open source
Limitations
  • Index ingestion, embedding, storage, and distribution happen on Moss Cloud, so you need project credentials and cannot build indexes entirely offline
  • Benchmark numbers are self-reported, and the comparison uses external embedding services for competitors, so absolute gains should be reproduced on your own data
  • Documentation and examples are English-first, which adds work for non-English teams
  • Python SDK needs 3.10+ and Node.js needs 20+, so older runtimes are unsupported

How does this agent compare with similar options?

The README benchmarks Moss against Pinecone (432.6 ms end-to-end P50), Qdrant (597.6 ms), and ChromaDB (351.8 ms), arguing those systems pay a remote round trip while Moss runs search and embedding in-process. It also states explicitly that Moss is not a database: there are no clusters to manage, no HNSW parameters to tune, and no sharding to consider.

Key facts side by side with the most closely related agents.

Agent Source review Form / cost Stars Updated Language Full support on
Moss This agent 59 · Major gaps Library / SDKFreemium ★ 682 2d ago Python —
MCP Memory Service 68 · Some gaps MCP serverFree ★ 2k today Python ChatGPT · Codex · Claude Code · Claude.ai
RAGLight 63 · Some gaps CLIFree + model costs ★ 672 1mo ago Python OpenAI API
AgentOS 52 · Major gaps Library / SDKFree + model costs ★ 673 today TypeScript Claude Code · OpenAI API · Claude API

How does FollowAgents rate this agent?

FollowAgents source review · FARS-2.1
Major gaps
59/ 100 5-point scale 3.0 / 5
Trust 12/29
Reliability 8/14
Adaptability 14/18
Convention 12/18
Effectiveness 9/13
Verifiability 4/8
Why each dimension lost points
Trust12 / 29 · 2.1/5

Permission surface is restrained: the SDK embeds in-process, CI workflows all declare contents: read, and the Codex review workflow structurally isolates fork code (diff-artifact-only, SHA-pinned action) — credit due. Deductions: no rollback/recovery mechanism for index or config changes (rollback 0); README does not warn about project_key exposure in browser/WASM scenarios (sensitive_data_handling 1); dependency security rests only on version overrides and a pinned ruff, with no audit evidence (1); cloud-side effects like create_index are mentioned only in passing (1); no user-confirmation design for tool flows (1). Attribution is clear (Moss team, YC, contributors) though publisher identity is unverified by the registry (2).

Reliability8 / 14 · 2.9/5

CI covers a Python multi-version matrix, Node matrix, lint/type-check/pytest; ruff is pinned with a regression rationale; lockfiles and engines are declared (dependency_availability 2). The agora middleware tests show failure paths, fail-open streaming, a doctor self-check entrypoint and 401 auth (failure_messages 2). Deduction: README says Elixir/C SDKs are available while Contributing lists Elixir as a wanted binding, and the PyPI badge points to the old inferedge-moss-core package — self-inconsistency (self_consistency 1).

Adaptability14 / 18 · 3.9/5

Scenario coverage is excellent: voice agents, browser WASM, Docker local stack, MCP, 20+ framework integrations, Python 3.10–3.14 and Node 20/22 (audience 3, environment_fit 3). The 'search runtime, not a database' framing sets boundaries (2). Deductions: tool-trigger precision relies on a few MCP examples with no systematic trigger design (1); capacity/consistency limitations beyond latency are largely undisclosed.

Convention12 / 18 · 3.3/5

Directory tree, docs site, quickstart, .env example and per-example run instructions are complete (information_architecture 3, install_notes 3); BSD-2-Clause LICENSE present and consistent (license 3); SECURITY.md includes a supported-version table and response timeline (maintenance 2). Deductions: no CHANGELOG (versioning 1), unstable naming — PyPI badge uses inferedge-moss-core while npm uses @moss-dev/moss (1), no known-limitations section (1), examples are rich but there is no FAQ (2).

Effectiveness9 / 13 · 3.5/5

Query results expose score, top_k and timing fields and print directly (output_usability 2). The in-process retrieval differentiator versus vector DBs is clearly argued with an aligned benchmark table (marginal_value 2). Deduction: strong dependence on a Moss Cloud account and managed index, with migration cost and vendor lock-in not discussed (cost_benefit 2, not higher).

Verifiability4 / 8 · 2.5/5

Benchmark claims include a reproduction path (./benchmarks/), hardware, query counts and measurement scope (claim_traceability 2); marketing claims are mostly separated from benchmark results (2). Deduction: all performance and integration claims are self-reported within this repository and cannot be corroborated across sources in a static review (cross_source_corroboration 1).

Risks and how to mitigate them
  • Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
  • All performance figures (<10ms, benchmark comparisons) are self-reported; this is a static review with no executed reproduction — run benchmarks/ yourself before adoption.
  • README does not warn that project_key is exposed client-side in the browser/WASM scenario; assess key leakage and quota abuse before shipping frontend retrieval.
  • Indexing and distribution fully depend on Moss Cloud hosting — vendor lock-in risk; no documented local index persistence or rollback mechanism.
  • Package naming shows migration traces (inferedge-moss-core vs moss); confirm you are installing the intended package and version.
  • Dependency security evidence is limited to version overrides and a pinned ruff, with no lockfile audit or SBOM; audit independently before production use.
Evidence confidence: Low Reviewed Sep 27, 2026 Reviewed revision 38f5cb261f5f
See the full review method →

FAQ

Do I have to pay to use Moss?
The README says a free tier is available after signing up at moss.dev for project_id and project_key. The repository code is BSD-2-Clause, but indexes are hosted on Moss Cloud, so cost depends on your plan there.
Does my document data leave my machine?
Yes. Per the architecture section, Moss Cloud handles ingestion, embedding, storage, and distribution; the runtime only pulls indexes over HTTPS and serves queries locally. If data cannot go to an external service, this model does not fit.
Can it run with no server at all?
The @moss-dev/moss-web WebAssembly package queries indexes entirely client-side, which removes the server from the query path, but the index itself is still built and distributed by Moss Cloud.
How is this different from a vector database?
The README states Moss is not a database but a search runtime: you index documents, load them into the runtime, and query, without managing clusters, tuning HNSW parameters, or worrying about sharding.
View on GitHub ↗ Install ↓

Compare agents like this one

The same FARS review applied across the shortlist this agent qualifies for.

Related agents