Subnet 102: ConnitoAI
ConnitoAI is Bittensor Subnet 102, a subnet for collaborative, decentralized training of large AI models. Its on-chain description captures the idea: contributors train specialized expert modules that are aggregated into powerful AI systems, without massive centralized compute. The codebase for the subnet is Connito-AI/Connito, and the Connito README source describes Subnet 102 as distributed mixture-of-experts training.
What ConnitoAI Rewards
Training a large model usually means running one very large network on a single concentration of expensive hardware. ConnitoAI takes the opposite approach, using a mixture-of-experts design: instead of one monolithic model, the system is made up of many smaller specialists, and the work of training those specialists is spread across many independent contributors. Each contributor can train a piece on more modest hardware, and the pieces are combined into a single, more capable model.
The subnet rewards contributors for the experts they bring to that shared model, so reward follows useful contribution to the collective system rather than raw compute owned by any one participant. This is what lets a capable model be assembled without a single party needing to own a massive, centralized training cluster.
Expert Module Context
Connito’s project explanation frames the subnet around isolated expert modules. Instead of changing one shared set of model weights for every new capability, the system trains specialists that can be combined inside a larger architecture. That matters because independent experts can improve different capabilities without every contributor needing to retrain the whole model.
For a Bittensor subnet, this turns model training into a coordination problem. The network needs many contributors to train useful pieces, and it needs validators to decide which pieces improve the shared system. The mixture-of-experts structure is what makes parallel contribution plausible: each miner can work on a narrower expert while still contributing to a larger model.
Contribution Quality Context
Connito’s docs also emphasize that expert contributions should compound over time. A useful expert does not only help a single training job; it can become part of a growing library of capabilities that future work can build on. This makes the subnet collaborative training rather than isolated model outsourcing.
The quality problem is deciding which expert contributions actually help. The public explanation describes validators scoring quality with Proof-of-Loss, while the repository README describes validators aggregating contributions and scoring miners for rewards. In plain terms, miners are not paid for merely submitting an expert module; they are rewarded when the submitted work improves the larger training system enough for validators to weight it.
Miner and Validator Roles
Miners are the contributors. Each one trains a specialized expert and submits it to the network, and miners are rewarded according to how much their expert improves the overall model. Because the specialists are independent, many miners can work in parallel on different parts of the same system.
Validators coordinate the collaboration and decide how reward is shared. They organize the training process, combine the experts that miners contribute into the aggregate model, and score each miner on the quality and usefulness of its contribution. Those scores determine how validators set weights on the network, which is how reward flows through Yuma Consensus. At the article level the split is straightforward: miners train and supply experts, while validators aggregate the contributions, judge them, and weight the network.
Source and Live Data
The public project site is connito.ai, and the codebase is maintained in the Connito-AI/Connito repository. Live SN102 subnet data is available on TaoStats. The mechanism context in this article is tied to the project site, public explanation, and README rather than to live identity fields alone.
Relationship to Yuma Consensus
Subnet 102 uses Yuma Consensus to convert the expert-contribution quality weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The linked documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In ConnitoAI’s context, validators organize the collaborative training process, combine the expert modules that miners contribute into the aggregate model, and score each miner on the quality and usefulness of its contribution using Proof-of-Loss, then translate those scores into weight vectors for the subnet. The Emission documentation describes how those 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 ConnitoAI (SN102), that sequence changes how readers should interpret collaborative mixture-of-experts training examples and contribution-quality scoring outcomes.
In localnet, ConnitoAI-compatible miners and validators can be developed and tested in an isolated environment. Localnet expert module evaluation results and emission outcomes do not represent production subnet performance.
On testnet, ConnitoAI-compatible distributed training workflows can be exercised in a shared, non-production network. Testnet contribution scores and validator weights are separate from mainnet subnet state.
On mainnet, ConnitoAI (SN102) is the live production subnet where miners train and submit specialized expert modules and validators aggregate those contributions and score their quality to determine real Bittensor emissions. The ConnitoAI repository describes the mechanism that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. An expert contribution score or emission outcome from one environment should not be read as representing production subnet performance in another environment.
Netuid 102 Identifies the Subnet On-Chain
Bittensor assigns every subnet a unique numeric identifier called a netuid, and Subnet 102 is the subnet registered at netuid 102 (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 ConnitoAI from every other subnet.
For a reader, this means “Subnet 102” and “netuid 102” refer to the same on-chain slot. A claim about ConnitoAI 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 102 ConnitoAI should not be read as generic Bittensor subnet documentation, a released production model, or a guarantee about the combined model’s quality. It names one subnet for collaborative AI training where many contributors each train a specialized expert and the experts are combined into one larger model on netuid 102 (Understanding Subnets, Glossary: Netuid).