Jack Dorsey's AI-agent chat app burns 758% CPU just to load

Every human and every agent in Buzz gets the same kind of key

Jack Dorsey announced Buzz on X, and Block open-sourced the whole project on GitHub the same day. The pitch, in the project's own words: "an open-source, self-hosted workspace that combines team chat, AI agents and Git hosting using signed Nostr events, so teams can keep control of their data." Nostr (a decentralized protocol where every action is a cryptographically signed event, with no central database of record) is the backbone: chat messages, code commits, workflow steps and approvals are all just signed events on a relay you can run yourself.

The identity model is the actual pitch. Per Block's own engineering writeup, every agent gets its own key; its human owner signs a narrowly scoped authorization, and the agent then signs its own work under its own identity. Leak an agent's key and you revoke just that key, while the human behind it keeps their access. Buzz is written in Rust, and it can even offload an agent's model requests onto another community member's machine, an idea the engineering writeup left unexplained.

The launch screenshot is fake, and the real site burns CPU

The chat screenshot circulating with the launch, engineers and bots swapping emoji in a channel called #engineering, turned out to be staged: every message in it is timestamped 5:42, meaning it's seeded test data or a mockup, not a real team's history. The live product fared worse under scrutiny than the marketing image. Loading buzz.xyz alone pinned one visitor's Firefox at 758% processor usage, and another reported the page running at roughly 5 frames per second on a 2019 machine, before a single message, agent or repository was involved.

A commenter with over 11,000 karma pointed out this isn't even the first product called Buzz to promise a rethink of team communication:

"Google literally launched a product along similar social themes named 'Google Buzz,' which lasted all of like 16 months in 2010, well before agents and llms."

Whose problem the identity layer actually solves

An engineer at Slack, disclosing that affiliation upfront, argued Buzz is solving the easier half of the hard problem:

"The challenge comes when you want to make certain things private to certain people. In that world you don't want multiplayer agents leaking data, so you end up having to write and maintain complex rulesets about what specific resources agents have access to."

A commenter posting from a Block-tagged account, who had already linked and walked through the company's own engineering post elsewhere in the thread, argued the design's value sits somewhere else entirely:

"Nostr gives you and your agents a durable, portable identity across communities/relays/workspaces. You can also independently verify that the messages you're reading came from the person/agent who sent them, even if the server/relay operator is broken or trying to trick you."

That claim didn't survive a close read. A commenter who quoted Block's own writeup back at itself, sentence by sentence, walked through what the framing was hiding:

"You're explicitly picking a bot per person, you're just calling them an agent. But you never really admit this because you call it 'an agent' rather than 'the user's agent'. … Just like you revoke an app-key on GitHub/Slack. This isn't a revolutionary thing you're doing."

The competitor Buzz should worry about isn't Slack

A commenter who had just finished surveying competing git forges built for AI agent swarms thought Buzz fills a real gap in private-repo agent identity, but not for long:

"This could fill a useful niche. However I would assume Anthropic and OpenAI are going to build their own and steamroll in 6-12 months. … Their latest product is Tag which is an auth model for running agents async within Slack. The obvious next feature to build from there is the forge."

Buzz's bet is that the protocol will end up mattering more than whichever chat app currently sits on top of it. Anthropic's bet, so far, is the opposite: own the auth layer inside the incumbent, and let the forge follow later.