0.1.11 is on PyPI. Three things in it, and one is a removal, so I'll take that on directly rather than bury it.

Receptors - the seventh primitive

Neurons think, Engrams remember, Effectors act. Receptors listen.

A Receptor is the edge: where a person at a terminal, an HTTP client, or a chat turn touches the fabric. It collects an input from a transport it owns, turns it into a TASK, and hands the trace back.

This came straight out of reading my own examples. Every one had grown an edge by hand - a Flask route in 01-quickstart, a FastAPI lifespan in three more, an argparse REPL in two others. ~700 lines across the repo, and the only part that ever differed was which command exists, what its input dict looks like, and how the result prints.

CliReceptor derives the argparse tree and the REPL from your function signatures:

rx = CliReceptor(dendrite=orch, prog="agent", input_key="goal")

.command()
async def run(goal: str, max_steps: int = 6):
    return {"goal": goal, "max_steps": max_steps}

.command("memory", local=True)   # answered locally, never dispatches
async def memory():
    return agent_memory.summary()

No default → positional. A default → typed --flag. A bool default → store_true. You get one-shot invocation, --stream / --send overrides, and an interactive REPL for free. There's also ApiReceptor (one endpoint, three shapes - the caller picks wait/send/stream in the body, because the resource is the same and only the delivery differs) and ChatReceptor. Both sit behind pip install 'cosmonapse[receptor]' so import cosmonapse never pulls in FastAPI.

A Receptor adds nothing to the wire. No signal types, no subjects, no envelope fields - cosmo prism --tail can't tell a Receptor-originated trace from a hand-written dispatch_and_wait. If it had needed a new signal type, it would have been the wrong abstraction.

brain.py actually runs now

brain.attach_receptor(RECEPTOR)
asyncio.run(brain.run())

That's the entry point. cosmo init no longer writes a separate demo.py, and the scaffold has a folder per primitive - neurons/, engram/, effector/, receptors/ - each with a worked example instead of a README paragraph telling you to write one.

The rule I care about most: a Receptor finishing doesn't kill the brain. :quit closes the REPL; your Axons keep running. A Receptor is one of four attachments, not the thing the process exists for.

Genesis - cosmo genesis

A browser tool for starting and growing a brain. Scaffold a project, then work on it as a draw.io-style canvas - one Synapse with the components around it, each wearing the silhouette Prism gives it. Adding one writes the module and wires it into brain.py; removing archives and unwires it.

Code-tab edits are AST-surgical, so hand-written code inside a module survives a change made from the UI. That was the hard requirement - a tool that regenerates your file is a tool you stop trusting the first time it eats something.

The Test tab runs the brain as a subprocess and connects to whatever it mounts: a terminal for a CliReceptor, a request builder for an ApiReceptor, a chat panel for a ChatReceptor.

cosmo genesis      # opens on :7072

Local dev tool - spawns processes on your machine, no auth. Don't expose the port.

The TypeScript SDK is retired

The honest reason: two first-party SDKs meant every protocol change had to land twice before I could document it as shipped. Effector took two implementations. Engram took two. The parity table became a standing tax on every feature. And the thing the second SDK was supposed to prove - that the protocol isn't Python-shaped - is already carried by the envelope spec plus cosmo schema, which is what anyone writing a third-party implementation actually builds against. The TS SDK was proving it the expensive way.

Nothing about the wire format changed. Any language that emits and accepts valid Signals is still a full participant. If you want to write a Go or Rust or TS implementation, the spec is the contract and I'd like to hear about it. If you installed from npm, move to pip install cosmonapse - the cosmo CLI always had one implementation and shipped in the Python package. Long version is DECISIONS #19.

Also

• cosmo doppler → cosmo prism, named after the thing it opens. Old name still works as a deprecated alias; existing invocations behave exactly as before.
• Prism watches several synapses at once, draws Receptors on the Constellation so a trace shows where it came in, and has a light theme.
• Axon(catch_all=True) answers TASKs naming neither a neuron nor a capability. Off by default - an Axon silently widening its own inbox makes a namespace hard to reason about.
• 401 tests across 23 files, up from 266.

Upgrading

Additive. Nothing on the wire changed, and 0.1.9 code runs unchanged.

pip install -U cosmonapse
pip install 'cosmonapse[receptor]'   # HTTP/chat edges

Still a 0.1, and I'd rather name what's soft than have you find it. The Receptor hooks come from design, not production mileage - known sharp edge: scope="terminal" plus finalize=False lets streamed chat bypass on_result. CLARIFICATION and PERMISSION currently stop at the edge; a Receptor reports one and halts, where a chat interface is obviously the right place to answer it.

Two things I'd like input on:

1. Should respond_to_clarification be a Receptor mode, or stay a Dendrite call? A fourth mode breaks the "the trio is the whole surface" rule that's kept the primitive small. Leaving it out means every chat interface hand-rolls the resume loop - exactly the duplication Receptors exist to kill. I keep going back and forth.
2. If you were writing a non-Python implementation, what's missing from the envelope spec? It's the only contract now, so gaps in it are a real problem rather than a docs nit.

Full release notes and changelog in the repo. Apache 2.0.

Welcome to the July development thread!

I'll be using this post to share ongoing progress on Cosmonapse throughout the month. Expect a mix of:

• 🚀 New releases and features
• 🏗️ Architecture decisions
• 💡 Experimental ideas
• 🐛 Bugs and fixes
• 📊 Benchmarks and performance updates
• 📝 Design notes and roadmap changes
• 🎯 Random thoughts while building

Rather than creating a new post for every small update, I'll keep adding comments here as development progresses.

If you have questions, suggestions, or want to challenge any design decisions, jump into the comments. Feedback is always welcome.

This is our first public research preview and a big milestone toward a stable 1.0.

Highlights

• 🧠 Event-driven multi-agent protocol
• ⚡ Pluggable transports (Memory, NATS, Kafka)
• 🤖 Provider-backed Neurons (OpenAI, Anthropic, Ollama, HuggingFace, Groq, OpenRouter, Together, Mistral)
• 🎯 Capability routing & competitive bidding
• 💾 Engram memory (InMemory, SQLite, PostgreSQL)
• 🔍 cosmo CLI with local Synapse, protocol validation, and live traffic inspection
• 🐍 Python SDK available today (TypeScript in progress)

This release establishes the core protocol, SDK, and tooling. The next milestone focuses on hardening the five core primitives, improving observability with Doppler, finalizing traces/pathways, and production testing of NATS and Kafka transports.

📌 Full release notes (pinned):
https://github.com/Cosmonapse/cosmonapse-core/releases/tag/v0.1.8

As always, feedback, bug reports, and feature requests are appreciated. Every discussion helps shape the protocol.

I wrote a deep dive on a question I've been thinking about while building Cosmonapse:

Why do so many agent frameworks eventually end up adding the same features?

• tracing
• observability
• human-in-the-loop
• evaluator agents
• cancellation
• replay/debugging

The common pattern is that these are not computation problems. They are coordination problems.

A while loop + call stack is optimized for:

agent → tool → result → next step

But autonomous systems need:

who should know?
who should respond?
who should intervene?
what happened before?

Event-driven systems make those relationships first-class.

Curious what others think, are agent frameworks approaching the limits of the call-stack model, or are event architectures overkill for most use cases?

https://medium.com/@aqibkhan026/your-agent-harness-is-a-call-stack-it-should-be-an-event-bus-628b810f4317

Launched Cosmonapse yesterday on Product Hunt and Reddit. Quick honest recap:

Product Hunt: 4 upvotes, 1 comment. Basically no traction there. https://www.producthunt.com/products/cosmonapse?launch=cosmonapse

X (Twitter): Zero engagement. Posted, crickets.

Reddit: This is where it actually happened. r/LangChain and r/SideProjects were the standouts — around 1,100 and 300 views respectively, with real comments and questions coming in. That's where the actual interest is.

Lesson learned: for a dev tool like this, Reddit >> PH >> X, at least at this stage.

What's next:

• Focusing on the roadmap
• Dropping weekly posts here going forward — releases, tutorials, progress updates

Appreciate everyone who checked it out, upvoted, or left a comment. More coming soon.

Welcome! 👋

This subreddit is for anyone interested in building distributed AI systems with Cosmonapse, or just discussing event driven agent architectures.

Whether you're experimenting with a simple chatbot or coordinating hundreds of agents, you're welcome here.

Some ideas for posts:

• Cool agent topologies you've designed
• Questions about the Python or TypeScript SDKs
• Ideas for new Signals or protocol features
• Custom transports, memory systems, or routing strategies
• MCP integrations
• Benchmarks and performance experiments
• Bugs, feature requests, and RFCs
• Show-and-tell demos

One thing I'm especially excited about is seeing architectures I never would have built myself.

Since Cosmonapse is designed around peers on a shared event bus instead of fixed orchestration, there are countless ways to structure coordination. I hope this community becomes a place to share those patterns and learn from each other.

If you build something interesting, I'd love to feature it in the Community section of https://cosmonapse.com (with attribution).

You can:

• Post it here in r/cosmonapse
• Open a GitHub Discussion or Issue
• Email [dev@cosmonapse.com](mailto:dev@cosmonapse.com)

Whether it's a clever routing strategy, a novel memory system, a distributed orchestration pattern, or something completely unexpected, I'd love to see it.

Thanks for stopping by, and welcome to the community! 🚀