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
- FA score
- 59/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changes
- Cost
- Free tier plus a paid hosted plan
- Setup effort
- Low · running in minutes
- You'll need
- 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
- Source review
- 59/100 · Major gaps 1 safety controls not found
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.
- Developers building voice customer-support agents where retrieval latency above a few milliseconds makes conversation feel laggy.
- Backend teams assembling a RAG stack who would rather embed the runtime than operate a vector database cluster.
- Frontend teams building static sites or browser extensions that need client-side semantic search via the WebAssembly SDK.
- Teams already on LangChain, LlamaIndex, DSPy, or CrewAI who want to swap in a lower-latency retriever.
- Builders of Pipecat, LiveKit, Vapi, or ElevenLabs voice pipelines that need retrieval inside a real-time audio loop.
- 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 mossTypeScript / Node.js requires 20+:
npm install @moss-dev/mossFor the browser, use the separate WebAssembly package:
npm install @moss-dev/moss-webTo 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.pyHow 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?
- 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
- 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?
Why each dimension lost points
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).
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).
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.
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).
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).
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).
- 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.