Subnet 118: Ditto
Ditto is Bittensor Subnet 118. The live Finney identity lists its subnet name as Ditto, its GitHub source as the ditto-assistant organization repositories page, its subnet URL as https://heyditto.ai, and its description as “Open-Source Claude Cowork.”
The current public Ditto repositories focus on memory and agent integrations. The Ditto CLI README
describes @heyditto/cli as a tool for saving, searching, fetching, and traversing a Ditto memory
graph, while the Claude plugin README describes a Claude Code integration that adds persistent
personal memory with prompt-time recall and write-back of salient turns.
What Ditto Provides
Ditto provides an assistant-memory layer for AI coworking workflows. Its public materials describe a memory graph that can store user or agent context, retrieve relevant memories, fetch detailed memory records, and traverse related memories through subjects or network links.
Ditto also publishes integration surfaces for different agent environments. The MCP README describes a local stdio MCP bridge to Ditto’s hosted MCP service, and the Claude plugin README describes a plugin that connects Claude Code to Ditto memory through recall and write-back surfaces.
Memory Graph Context
The Ditto CLI README source describes Ditto memory as a graph that can be saved to, searched, fetched, and traversed. That wording is important because the project is not presented only as a note store. Its public CLI surface includes search across memories, retrieval of detailed memory records, subject search, memories scoped to subjects, and traversal of a memory’s related network.
The public Ditto website frames the product as a shared home for agent context across threads, tools, and workflows. Read with the CLI source, that makes the subnet’s public materials more specifically about reusable assistant context than about one-off chat logs. The useful object is a memory graph that agents can query and extend over time.
This distinction also helps explain why the article avoids describing a subnet-specific miner reward mechanism. The available sources are strongest on Ditto’s memory and integration surfaces: what can be stored, how memories are searched, and how related subjects or network links make context reusable.
Integration Surface Context
Ditto’s MCP README source describes a local stdio bridge to Ditto’s hosted MCP service. The Claude plugin README source describes a Claude Code plugin with prompt-time memory recall and write-back of salient turns.
Those sources describe two complementary integration paths. MCP presents Ditto memory through a model-context interface that can be used by compatible clients, while the Claude plugin presents a client-specific workflow for recall and saving. Both are about making persistent memory available inside agent work, rather than about replacing the agent or model that performs the work.
For readers comparing Ditto with other subnets, the source-backed focus is persistent context. The public materials emphasize memory storage, retrieval, traversal, and agent integration; they do not publish a detailed Subnet 118 validator rubric or miner scoring process in the inspected sources.
References: Ditto CLI README source, Ditto MCP README source, Ditto Claude plugin README source, Ditto website
Miner and Validator Roles
The public identity and inspected repositories do not describe subnet-specific miner tasks, validator prompts, or scoring rules for Subnet 118. This article therefore avoids claims about Ditto’s incentive mechanism beyond the general Bittensor pattern.
In Bittensor, miners generally perform the work requested by a subnet, while validators evaluate miner outputs and submit weights that flow through Yuma Consensus. For Ditto, the exact subnet-specific responsibilities should be confirmed from public operator documentation before adding implementation-level detail. The broader pattern is covered in Mining and Validating.
On-Chain Identity
Live SN118 subnet data is available on TaoStats. The source-backed memory and integration details in this article come from Ditto’s public website and README sources rather than from live identity fields.
Relationship to Yuma Consensus
Subnet 118 uses Yuma Consensus to convert validator weight vectors into the emission shares distributed to miners and validators within the subnet each tempo. The Yuma Consensus documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
The inspected Ditto public repositories focus on memory storage, retrieval, and agent integrations rather than on a subnet-specific validator scoring rubric or miner task description. The Emission documentation describes how consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Ditto (SN118), that sequence applies to the standard Bittensor lifecycle: localnet for isolated development, testnet for shared non-production testing, and mainnet for live operation with real emissions.
On mainnet, Ditto (SN118) is registered as the live production subnet at netuid 118. The Bittensor Networks reference separates mainnet, testnet, and localnet. Participation examples or emission outcomes from one environment should not be read as representing production subnet performance in another environment.
Netuid 118 Identifies the Subnet On-Chain
Bittensor assigns every subnet a unique numeric identifier called a netuid, and Subnet 118 is the subnet registered at netuid 118 (Glossary: Netuid). The Understanding Subnets reference explains that each subnet runs its own incentive mechanism while sharing the same underlying Subtensor chain, so the netuid is the stable handle that distinguishes Ditto from every other subnet.
For a reader, this means “Subnet 118” and “netuid 118” refer to the same on-chain slot. A claim about Ditto should be tied to that netuid rather than to the registered name alone, because the name field can be changed on-chain while the netuid stays fixed.
Reader Boundary
Subnet 118 Ditto should not be read as generic Bittensor subnet documentation, an official Anthropic or Claude product, or a guarantee about how any integrated assistant behaves. It names one open-source assistant-memory subnet whose public materials focus on persistent memory and agent integrations on netuid 118 (Understanding Subnets, Glossary: Netuid).