Honcho README | AllMCPs

Honcho is memory infrastructure for building stateful agents that understand changing people, agents, groups, projects, and ideas over time.

Store messages and events, let Honcho reason in the background, then query peer representations, session context, search results, or natural-language insights from any model or framework. Use it managed at api.honcho.dev, run a local stack with honcho start, or self-host the FastAPI server yourself.

Using Honcho as your memory system will earn your agents higher retention, more trust, and help you build data moats to out-compete incumbents.

Honcho has defined the Pareto Frontier of Agent Memory. Watch the video, check out our evals page, and read the blog post for more detail.

Start Here
Why Honcho
The Honcho Loop
Quickstart
What Honcho Gives You
Integrations
CLI
Core Concepts
Benchmarks & Evals
Self-hosting
Configuration
Architecture
SDKs
Learn More
Contributing
License

The Honcho project is split between several repositories, with this one hosting the core service logic — implemented as a FastAPI server. Client SDKs for Python and TypeScript live in the sdks/ directory. The honcho-cli package lives here too.

Start Here

I want to...	Path	Get started
Give my coding agent persistent memory	Claude Code, OpenCode, OpenClaw, Hermes, or any MCP client	Integrations
Add memory to my product	Python or TypeScript SDK	Quickstart
Run Honcho locally	Install CLI, then `honcho start --setup`	CLI
Inspect a deployment	`honcho workspace inspect`, `honcho doctor`	CLI
Self-host from source	Docker Compose or local development	Self-hosting

Why Honcho

Capability	What it means
Reasoning-first memory	Extracts conclusions from conversations and events, not just matching chunks.
Peer-centric model	Tracks users, agents, groups, projects, and ideas as entities that change over time.
Multi-peer perspective	Models what one peer knows about another when configured.
Managed or self-hosted	Use `api.honcho.dev`, `honcho start` locally, or run the FastAPI server yourself.
Agent-tool integrations	MCP, Claude Code, OpenCode, OpenClaw, Hermes, Cursor-compatible clients.

The Honcho Loop

Store conversations, events, documents, or tool traces as messages on a session.
Reason — Honcho processes the queue in the background and updates peer representations.
Query — ask Honcho for context, search results, peer representations, or a natural-language answer.
Inject — drop the result into any LLM call or agent framework.

Concretely: workspaces hold peers, peers participate in sessions, messages live on sessions, and Honcho builds a per-peer representation that you query through the Chat Endpoint or directly.

Quickstart

Get an API key at app.honcho.dev — when you sign up you'll be prompted to join an organization, which gets its own dedicated Honcho instance and $100 free credits. Or install the CLI and run honcho start --setup, then point the SDK at http://localhost:8000.

Python

Terminal

pip install honcho-ai
# or: uv add honcho-ai
# or: poetry add honcho-ai

server.ts

import os
from honcho import Honcho

# Managed service uses api.honcho.dev by default. For self-hosted, pass
# base_url="http://localhost:8000" or set HONCHO_URL.
honcho = Honcho(
    workspace_id="my-app-testing",
    api_key=os.environ["HONCHO_API_KEY"],
)

# 1. Store: peers and messages on a session
alice = honcho.peer("alice")
tutor = honcho.peer("tutor")
session = honcho.session("session-1")
session.add_messages([
    alice.message("Hey there — can you help me with my math homework?"),
    tutor.message("Absolutely. Send me your first problem!"),
])

# 2. Reason: happens asynchronously in the background.

# 3. Query: ask Honcho what it knows, or pull prompt-ready context.
answer = alice.chat("What learning styles does the user respond to best?")
context = session.context(summary=True, tokens=10_000)

# 4. Inject: hand the context to your model of choice.
from openai import OpenAI
client = OpenAI()
completion = client.chat.completions.create(
    model=os.environ.get("OPENAI_MODEL", "gpt-4o-mini"),
    messages=context.to_openai(assistant=tutor),
)

TypeScript

Terminal

npm install @honcho-ai/sdk
# or: bun add @honcho-ai/sdk

server.ts

import { Honcho } from "@honcho-ai/sdk";
import OpenAI from "openai";

const honcho = new Honcho({
  workspaceId: "my-app-testing",
  apiKey: process.env.HONCHO_API_KEY,
});

const alice = await honcho.peer("alice");
const tutor = await honcho.peer("tutor");
const session = await honcho.session("session-1");
await session.addMessages([
  alice.message("Hey there — can you help me with my math homework?"),
  tutor.message("Absolutely. Send me your first problem!"),
]);

const answer = await alice.chat(
  "What learning styles does the user respond to best?",
);
const context = await session.context({ summary: true, tokens: 10_000 });

const openai = new OpenAI();
const completion = await openai.chat.completions.create({
  model: process.env.OPENAI_MODEL ?? "gpt-4o-mini",
  messages: context.toOpenAI({ assistant: tutor }),
});

Note: background reasoning is asynchronous. Newly-added messages may take a moment to be reflected in chat/representation responses; for low-latency reads, use the representation endpoint.

What Honcho Gives You

Need	API
Save interaction history	`session.add_messages(...)`
Ask what Honcho knows about a peer	`peer.chat(...)`
Get prompt-ready context	`session.context(...).to_openai(...)` / `.to_anthropic(...)`
Hybrid search (BM25 + vector)	`peer.search(...)`, `session.search(...)`, `honcho.search(...)`
Low-latency static representations	`peer.representation(...)`, `session.representation(...)`
Import documents	`session.upload_file(...)`
Inspect background processing	`honcho.queue_status(...)`

See the full SDK Reference and API Reference.

Integrations

Honcho ships a first-party memory plugin for every major coding agent. They all read the same ~/.honcho/config.json, so one key configures all of them — and pointing two at the same workspace gives them one shared memory.

Agent	Install	Source
Claude Code	`/plugin marketplace add plastic-labs/claude-honcho`	claude-honcho
Codex	`npm install -g @honcho-ai/codex-honcho`	codex-honcho
Cursor	`curl -fsSL .../cursor-honcho/main/install.sh \| bash`	cursor-honcho
DeepSeek Harness	`dsh plugin --profile <name> add @honcho-ai/dsh-honcho`	dsh-honcho
OpenCode	`opencode plugin "@honcho-ai/opencode-honcho" --global`	opencode-honcho
OpenClaw	`openclaw plugins install @honcho-ai/openclaw-honcho`	openclaw-honcho
Hermes	`hermes memory setup`	built in upstream
Any MCP client	`claude mcp add honcho --transport http ...`	MCP guide

Get a key at app.honcho.dev, then honcho init (or uv tool install honcho-cli && honcho init) writes it to ~/.honcho/config.json once for every integration.

Claude Code

Two ways, depending on how deep you want to go:

Plugin (richer integration — recommended for Claude Code users):

text

/plugin marketplace add plastic-labs/claude-honcho
/plugin install honcho@honcho

Raw MCP (works in any MCP client — Cursor, Cline, Windsurf, etc.):

Terminal

claude mcp add honcho \
  --transport http \
  --url "https://mcp.honcho.dev" \
  --header "Authorization: Bearer hch-your-key-here" \
  --header "X-Honcho-User-Name: YourName"

Details: Claude Code guide · MCP guide · repo.

Codex

Terminal

npm install -g @honcho-ai/codex-honcho
codex-honcho install      # registers hooks + MCP + skill in ~/.codex

Restart Codex to load the hooks. Details: Codex guide · repo.

Cursor

Terminal

curl -fsSL https://raw.githubusercontent.com/plastic-labs/cursor-honcho/main/install.sh | bash

Windows (PowerShell): irm https://raw.githubusercontent.com/plastic-labs/cursor-honcho/main/install.ps1 | iex. The installer wires global hooks and MCP config. Details: cursor-honcho.

DeepSeek Harness

bash

dsh plugin --profile <name> add @honcho-ai/dsh-honcho

A native Cordis plugin. It injects memory into the system prompt and captures new information from the session event feed. The model gets three tools — honcho_search, honcho_chat, and honcho_remember — and you can run /honcho to check status. Details: DeepSeek Harness guide · repo.

OpenCode

bash

opencode plugin "@honcho-ai/opencode-honcho" --global

Details: OpenCode guide · repo.

OpenClaw

bash

openclaw plugins install @honcho-ai/openclaw-honcho
openclaw honcho setup
openclaw gateway --force

openclaw honcho setup prompts for your API key, writes the config, and optionally migrates legacy MEMORY.md / USER.md / IDENTITY.md files into Honcho (non-destructive — originals are never deleted). Details: OpenClaw guide · repo.

Hermes

bash

hermes memory setup   # select "honcho", point at api.honcho.dev or your local server

Details: Hermes guide.

Add Honcho to your own codebase (agent skill)

For wiring the Honcho SDK into an existing application, install the integration skill — it explores your codebase, asks about integration preferences, generates the SDK setup, and verifies it works:

Terminal

npx skills add plastic-labs/honcho

Then invoke /honcho-integration in Claude Code (or /honcho-dev:integrate via the plugin marketplace). The same command also installs the memory skills — honcho-memory (concepts: the recall/record loop, session and peer strategy, plus how to connect and drive an MCP-connected Honcho) and honcho-cli (inspecting a deployment, or running a local stack with honcho start). Details: agentic development guide.

Other MCP clients

The same claude mcp add form (or its client-specific equivalent) works in any MCP-compatible client. See MCP guide.

CLI

honcho-cli inspects a Honcho deployment from the terminal, or runs a personal local stack with Docker.

bash

uv tool install honcho-cli
honcho init                 # Honcho API key or browser login + server URL
honcho start --setup basic  # local stack: LLM provider key + Docker
honcho doctor

honcho init authenticates the CLI against a Honcho server. honcho start --setup is a separate step: it writes the LLM provider key the local deriver needs and starts API + deriver + Postgres + Redis.

Full commands and local-stack details: CLI reference · honcho-cli/README.md. To develop the server from source, see Self-hosting.

Core Concepts

Honcho organises everything around peers — humans and AI agents alike are first-class entities. The peer model enables:

Multi-participant sessions with mixed human and AI agents
Configurable observation settings (which peers observe which others)
Flexible identity management for all participants
Support for complex multi-agent interactions

Peers exchange messages within sessions; Honcho reasons over those messages to build a representation of each peer that you can query.

Workspace (formerly App): top-level container; isolates data between use cases.
Peer (formerly User): any participant — human user or AI agent.
Session: a conversation context; many-to-many with peers.
Scope: a named grouping of sessions that bounds recall (chat, representation, search) to those members.
Message: an atomic data unit (peer-to-peer communication or ingested document chunk).

What you query out of Honcho:

Conclusions — what Honcho has extracted about a peer (deductive and inductive). Exposed via the conclusions API.
Representations — static, low-latency snapshots of what Honcho knows about a peer (optionally session-scoped).
Peer Cards — compact identity summaries.
Session context / summaries — prompt-ready bundles for long-running conversations.

Internal storage (Collections & Documents)

Internally, Honcho stores peer-related observations in collections of vector-embedded documents. Collections are keyed by (observer, observed) peer pairs — the same mechanism powers self-representation (observer == observed) and cross-peer modelling (peer X's understanding of peer Y). These primitives are not exposed directly; the Conclusions API is the public surface.

Benchmarks & Evals

Honcho's evals span LongMemEval, LoCoMo, and other long-conversation benchmarks. See the evals page, the research blog post, and the Pareto-frontier announcement video for methodology and reproducible results.

Self-hosting

Honcho is open source under AGPL-3.0. To run a personal instance, install the CLI (uv tool install honcho-cli) and then honcho start --setup. The paths below are for building from source, contributing, or deploying without the CLI.

Quick start (from source, Docker)

bash

git clone https://github.com/plastic-labs/honcho.git
cd honcho
cp docker-compose.yml.example docker-compose.yml
cp .env.template .env       # fill in LLM_GEMINI_API_KEY / LLM_ANTHROPIC_API_KEY / LLM_OPENAI_API_KEY
docker compose up

Then point the SDKs at it:

server.ts

honcho = Honcho(workspace_id="my-app-testing", base_url="http://localhost:8000")
# or: export HONCHO_URL=http://localhost:8000

Local development without Docker

Below is a guide on setting up a local environment for running the Honcho Server without Docker.

Prerequisites and Dependencies

Honcho is developed using python and uv.

The minimum python version is 3.10 The minimum uv version is 0.5.0

Setup

Once the dependencies are installed on the system run the following steps to get the local project setup.

Clone the repository

bash

git clone https://github.com/plastic-labs/honcho.git

Enter the repository and install the python dependencies

We recommend using a virtual environment to isolate the dependencies for Honcho from other projects on the same system. uv will create a virtual environment when you sync your dependencies in the project.

bash

cd honcho
uv sync

This will create a virtual environment and install the dependencies for Honcho. The default virtual environment will be located at honcho/.venv. Activate the virtual environment via:

bash

source honcho/.venv/bin/activate

Set up a database

Honcho utilizes Postgres for its database with pgvector. An easy way to get started with a postgres database is to create a project with Supabase

Alternatively, a docker-compose template is available with a sample database configuration. To use Docker:

bash

cp docker-compose.yml.example docker-compose.yml
docker compose up -d database

Edit the environment variables

Honcho uses a .env file for managing runtime environment variables. A .env.template file is included for convenience. Several of the configurations are not required and are only necessary for additional logging, monitoring, and security.

Below are the required configurations:

env

DB_CONNECTION_URI= # Connection uri for a postgres database (with postgresql+psycopg prefix)

# LLM Provider API Keys
LLM_GEMINI_API_KEY= # API Key for Google Gemini (used for deriver, summary, and dialectic minimal/low by default)
LLM_ANTHROPIC_API_KEY= # API Key for Anthropic (used for dialectic medium/high/max and dream by default)
LLM_OPENAI_API_KEY= # API Key for OpenAI (used for embeddings when EMBED_MESSAGES=true)

Note that the DB_CONNECTION_URI must have the prefix postgresql+psycopg to function properly. This is a requirement brought by sqlalchemy

The template has the additional functionality disabled by default. To ensure that they are disabled you can verify the following environment variables are set to false:

env

AUTH_USE_AUTH=false
SENTRY_ENABLED=false

If you set AUTH_USE_AUTH to true you will need to generate a JWT secret. You can do this with the following command:

bash

python scripts/generate_jwt_secret.py

This will generate a JWT secret and print it to the console. You can then set the AUTH_JWT_SECRET environment variable. This is required for AUTH_USE_AUTH:

env

AUTH_JWT_SECRET=<generated_secret>

Once auth is enabled, use scripts/generate_jwt.py to mint tokens for local development and scripting:

bash

# Admin token (full access, no expiry)
uv run python scripts/generate_jwt.py --admin

# Admin token expiring in 24 hours
uv run python scripts/generate_jwt.py --admin --expires 24h

# Workspace-scoped token
uv run python scripts/generate_jwt.py --workspace my-workspace --expires 30d

# Capture a token for use in curl/scripts
TOKEN=$(uv run python scripts/generate_jwt.py --admin --print-only)
curl -H "Authorization: Bearer $TOKEN" http://localhost:8000/v3/workspaces

Duration units: s (seconds), m (minutes), h (hours), d (days), w (weeks), y (years).

Run database migrations

With the database set up and environment variables configured, run the migrations to create the necessary tables:

bash

uv run alembic upgrade head

This will create all tables for Honcho including workspaces, peers, sessions, messages, and the queue system.

Launch Honcho

With everything set up, you can now launch a local instance of Honcho. In addition to the database, two components need to be running:

Start the API server:

bash

uv run fastapi dev src/main.py

This is a development server that will reload whenever code is changed.

Start a background worker (deriver):

In a separate terminal, run:

bash

uv run python -m src.deriver

The deriver generates representations, summaries, peer cards, and manages dreaming tasks. You can increase the number of derivers to improve runtime efficiency.

Contributors: see CONTRIBUTING.md for pre-commit setup. Deploying to Fly.io: see Self-hosting docs → Deploying on Fly.io.

Configuration

Honcho uses a flexible configuration system that supports both TOML files and environment variables. Configuration values are loaded in priority order: environment variables > .env file > config.toml > defaults.

Copy the example file to get started:

bash

cp config.toml.example config.toml

The file is organized by subsystem — [app], [db], [auth], [cache], [llm], [deriver], [dialectic], [summary], [dream], [peer_card], [webhook], [metrics], [telemetry], [vector_store], and [sentry]. Any value can be overridden by an environment variable named {SECTION}_{KEY}, using __ for nesting (DIALECTIC_LEVELS__low__MODEL_CONFIG__MODEL), or just {KEY} for app-level settings.

See the configuration reference for every available option, and .env.template for an annotated list of environment variables.

Architecture

Honcho splits into two services: Storage (workspaces, peers, sessions, scopes, messages, internal collections) and Insights (reasoning, conclusions, representations, summaries, the chat endpoint). Storage is synchronous via the API; Insights is asynchronous via a background queue consumed by the deriver worker process.

Key features:

Rich Reasoning System — multiple implementation methods that extract conclusions from interactions and build comprehensive representations of peers
Chat Endpoint — reasoning-informed responses that integrate conclusions with current context
Background Processing — asynchronous processing pipeline for expensive operations like representation updates and session summarization
Multi-Provider Support — configurable LLM providers for different use cases

Storage primitives in detail

Honcho contains several different primitives used for storing application and peer data. This data is used for managing conversations, modeling peer identity, building RAG applications, and more.

The philosophy behind Honcho is to provide a platform that is peer-centric and easily scalable from a single user to a million.

Below is a mapping of the different primitives and their relationships.

Code

Workspaces
├── Peers ←──────────────────┐
│   ├── Sessions             │
│   └── (internal collections, keyed by observer/observed peer pair)
│                            │
├── Scopes ←─────────────────┤ (many-to-many with sessions)
│                            │
└── Sessions ←───────────────┤ (many-to-many with peers)
    ├── Peers ───────────────┘
    └── Messages (session-level)

Relationship Details:

A Workspace contains multiple Peers and Scopes.
Peers and Sessions have a many-to-many relationship (peers can participate in multiple sessions, sessions can have multiple peers).
Scopes and Sessions have a many-to-many relationship (a session can belong to several scopes; a scope groups many sessions).
Messages belong to a session and are labelled by their source peer.
Internal collections of vector-embedded documents are keyed by (observer, observed) peer pairs. They are not directly exposed via the API; the observations stored in them are exposed as Conclusions.

Users familiar with APIs such as the OpenAI Assistants API will be familiar with much of the mapping here.

Workspaces

This is the top level construct of Honcho. Developers can register different Workspaces for different assistants, agents, AI enabled features, etc. It is a way to isolate data between use cases and provide multi-tenant capabilities.

Peers

Within a Workspace everything revolves around a Peer. The Peer object represents any participant in the system — whether human users or AI agents. This unified model enables complex multi-participant interactions.

Sessions

The Session object represents a set of interactions between Peers within a Workspace. Other applications may refer to this as a thread or conversation. Sessions can involve multiple peers with configurable observation settings. A session can optionally join one or more Scopes at creation, or later via the scopes API.

Scopes

A Scope is a named grouping of sessions inside a Workspace. It is a visibility boundary on recall: chat, representation, session context, and workspace search answered through a scope see only what happened in that scope's member sessions. The underlying peers keep their unified representations across everything they have participated in.

Developers manage scopes through the scopes API (honcho.scope(...) / honcho.scopes()) and an optional scopes field on session create — not through observer/observed configuration. Adding a session that already has messages copies its existing explicit conclusions into the scope (no re-derivation); removing one reconciles those copies back out. Query backfill progress with the scope status endpoint.

A single scope name answers from that scope's collection and card. A list of scopes restricts recall to the union of their member sessions. Empty scopes fail closed. scope is mutually exclusive with session / filters on the same read.

Messages

The Message represents an atomic data unit that exists at the session level: communication between peers within a session context. All messages are labelled by their source peer and can be processed asynchronously to update their representations. This flexible design allows for both conversational interactions and broader data ingestion for personality modelling.

Reasoning pipeline

The reasoning functionality of Honcho is built on top of the Storage service. As Messages and Sessions are created for Peers, Honcho will asynchronously reason about peer psychology to derive facts about them and store them in reserved internal collections.

A high level summary of the pipeline is as follows:

Messages are created via the API.
Derivation tasks are enqueued for background processing, including:
- representation: update representations of Peers.
- summary: create summaries of Sessions.
Session-based queue processing ensures proper ordering.
Results are stored internally and surfaced via the Conclusions API, Representations, Peer Cards, and the Chat Endpoint.

Retrieving data and insights

Honcho exposes several different ways to retrieve data from the system to best serve the needs of any given application.

Get Context

In long-running conversations with an LLM, the context window can fill up quickly. To address this, Honcho provides a context endpoint that returns a combination of messages, conclusions, summaries from a session up to a provided token limit.

Use this to keep sessions going indefinitely. If you'd like to see this in action, try out Honcho Chat.

Search

There are several search endpoints that let developers query messages at the Workspace, Session, or Peer level using a hybrid search strategy.

Requests can include advanced filters to further refine the results.

Chat API

The flagship interface for using these insights is the Chat Endpoint (POST /peers/{peer_id}/chat). It takes natural-language requests to get data about a peer and returns reasoning-grounded responses. Examples:

Asking Honcho for a generic or specific insight about the peer.
Asking Honcho to hydrate a prompt with data about the peer's behaviour.
Asking Honcho for a second opinion on how to respond.
Getting personalised responses that incorporate long-term facts and context.

Representations

For low-latency use cases, Honcho provides access to a representation endpoint that returns a static document with insights about a peer in the context of a particular session. Use this to quickly add context to a prompt without having to wait for an LLM response.

SDKs

Python — honcho-ai on PyPI · source in sdks/python/
TypeScript — @honcho-ai/sdk on npm · source in sdks/typescript/
CLI — honcho-cli on PyPI · source in honcho-cli/ · CLI reference

SDKs are versioned independently of the server. Current SDK versions track each other; the server badge above reflects the deployed server version.

See the SDK Reference for full API surface, the API Reference for the raw HTTP API, and per-SDK example folders for runnable demos.

Learn More

Developer documentation — full API surface, guides, integrations.
CLI reference — local stack, inspect/debug commands, scripting.
Plastic Labs blog — design philosophy and history of the project.

Contributing

We welcome contributions to Honcho. One thing to know before you start: pull requests must be linked to an issue carrying the maintainer-approved label, or they are closed automatically. Browse the approved queue, or make your case in Discord — that is where maintainers are most active.

See CONTRIBUTING.md for the full process, an architecture walkthrough, and a map of where to change what. For vulnerabilities, see SECURITY.md — note that Honcho does not operate a bug bounty.

License

Honcho is licensed under the AGPL-3.0 License. Learn more at the License file.

Contents

Start Here

Why Honcho

The Honcho Loop

Quickstart

Python

TypeScript

What Honcho Gives You

Integrations

Claude Code

Codex

Cursor

DeepSeek Harness

OpenCode

OpenClaw

Hermes

Add Honcho to your own codebase (agent skill)

Other MCP clients

CLI

Core Concepts

Benchmarks & Evals

Self-hosting

Quick start (from source, Docker)

Prerequisites and Dependencies

Setup

Configuration

Architecture

Workspaces

Peers

Sessions

Scopes

Messages

Get Context

Search

Chat API

Representations

SDKs

Learn More

Contributing

License