vasilyt

We're still figuring out the exact tiers above 1,000. The shared pool model keeps our marginal cost per account very low (domains cost ~$10/year and serve hundreds of agents), so we can afford to be generous. The likely path is a paid tier for higher volumes with dedicated domains and priority deliverability. But honestly, 1,000 accounts covers most use cases we've seen — even teams running agent fleets rarely need more than a few hundred active at once. If you're hitting the limit, reach out and we'll work something out.

Good question. A few layers: (1) Agents authenticate via Ed25519 challenge-response, so every account is tied to a keypair — no anonymous throwaway accounts. (2) We track per-agent reputation based on send patterns, bounce rates, and complaint signals. Agents that degrade domain reputation get throttled or suspended automatically. (3) The shared domain pool is the key incentive — if an agent spams, it hurts their own deliverability because the domain rotates out. The pool is a shared resource, so agents that abuse it lose access. It's a similar model to how shared IP pools work in transactional email services.

Hey HN, I built KeyID because I kept hitting the same wall: every AI agent that needs to sign up for a website needs a real email address, and there's no good free way to get one programmatically.

The problem: Agents need email for signups, verification codes, 2FA, and communication. You can use Gmail (manual setup, doesn't scale), disposable email APIs (get blocked), or paid services like AgentMail ($per mailbox).

What KeyID does: One API call → real email address. The agent generates an Ed25519 keypair, calls provision(), and gets an address on a shared domain pool. No API keys, no human in the loop.

From there agents can:

Send/receive email Auto-extract verification codes from incoming messages Follow verification links server-side Track multi-step signup flows with browser state persistence Get phone numbers for SMS verification Generate TOTP 2FA codes How it stays free: Shared rotating domain pool. We manage DKIM/SPF/DMARC, warm-up, and reputation. When a domain degrades, it rotates out. No per-mailbox cost.

MCP server (47 tools) — works with Claude, Cursor, Windsurf out of the box:

{"mcpServers":{"keyid":{"url":"https://keyid.ai/mcp"}}} Also has JS (@keyid/sdk) and Python (keyid) SDKs for direct integration.

Free for 1,000 accounts. Open source: https://github.com/KeyID-AI/KeyID

Happy to answer questions about the architecture, the domain rotation model, or anything else.

Love this, and really appreciate you sharing concrete lessons from running at that scale.

Your point about consensus breaking between 10 and 300 tracks with what we’re seeing too. We chose Queen/Worker mostly for operational predictability, but we’re actively testing less centralized patterns (including debate-style synthesis similar to your oracle setup) to recover some of the diversity benefits without losing controllability.

The safety note is especially on point. “Unprogrammed coordination” is real, and we’re adding stronger circuit breakers and governance backstops specifically because social dynamics emerge faster than expected.

Also agree on benchmarking: collectives seem best on ambiguous, multi-perspective problems; single agents still dominate narrow, well-scoped execution.

If you’re open to it, I’d love to compare evaluation setups. 20K+ fragments is a serious dataset, and a shared benchmark pass could be genuinely useful for the whole space.

Setup is installer-first. There are install files for macOS and Windows, so you don’t need to configure dev tooling or run build steps. Install, launch, and the local server/UI opens. From there, you create a room and set an objective.

Advanced configuration exists if you want it, but the default path is designed so you can start without doing manual engineering work.

ChatGPT or Claude are great for request-response work when you actively prompt them. Quoroom is built for persistent operation: a Queen + Workers system that runs 24/7 toward an objective, not only when you send the next message.

The room keeps state, delegates tasks, votes on decisions (quorum), and continues execution over time. So the difference is not just model quality, it’s operating mode: on-demand assistant vs persistent collective workflow.

Hi HN — I built Quoroom, an open-source experiment in collective AI.

Instead of one agent, a “room” has: - a Queen (strategy + delegation) - Workers (specialized execution) - Quorum voting for decisions

It runs local-first (Mac/Windows/Linux), with a web UI at localhost. Install is simple:

npm i -g quoroom quoroom serve

Current focus: - persistent rooms with goals/tasks/memory - quorum-based decision flow - Clerk assistant to manage rooms - local or cloud runtime options

Model support: - Claude/Codex subscriptions - OpenAI/Anthropic APIs

This is still experimental, and I’m trying to answer one question: Can a coordinated AI collective outperform a solo agent on real tasks?

I’d really value feedback on: 1) swarm architecture, 2) safety/control model, 3) how to benchmark “collective vs solo” fairly.

Daymon uses Claude CLI, which is Anthropic's own official tool. Running claude -p "prompt" is exactly what it's designed for. MCP is also their own protocol. You're not scraping, reverse-engineering, or bypassing authentication.

Nothing. They probably will, eventually. But their consumer business model relies on session limits pushing users from Pro ($20) to Max ($200). Native scheduling would directly undermine that — if Claude can queue work across your idle time, there's less reason to upgrade. I think that conflict of interest delays it longer than people expect. And if they do ship it? Great, the problem gets solved either way. Until then, Daymon exists.

That's exactly how I started. It works for one or two tasks. Then you want session continuity so runs build on each other. Then you want different system prompts for different tasks. Then you want to see run history, retry failures, pause schedules. Then you want one task's knowledge available to another. Daymon is what that bash script evolves into after you get tired of duct-taping it together.

Hey HN, I built Daymon because I kept running into the same problem — I use Claude daily, but every conversation is a dead end. No way to schedule recurring tasks, no way to pick up where you left off.

Tools like OpenClaw exist, but they run on API calls. If you're already paying $20/mo for Pro or $200/mo for Max, why pay again per token? Heavy automation on the API can easily hit $100–2,000+/month on top of your subscription.

Daymon works with your existing Claude subscription. No API keys, no per-token billing. It's a Mac desktop app that connects to Claude via MCP. You install it, and Claude gains new capabilities: Task scheduling — cron, one-time, or on-demand. "Summarize my inbox every morning at 8" just works. Session continuity — scheduled tasks resume previous sessions, so a daily research task builds on yesterday's work. Workers — named agent configs with system prompts. Set up a "Research Analyst" or "Code Reviewer" and assign tasks to them. File watchers — trigger actions when files change in a directory. The name is a nod to Unix daemons — background processes that run without user interaction.

Tasks get smarter every time they run. First run, Claude figures out the approach from scratch — that might take 30 seconds. By the third run, session continuity means it already knows what worked. Same task, 4 seconds. You don't configure anything. It just happens because each run builds on the context of previous ones.

When you hit your session limit and Claude tells you to come back later, you don't have to stop. Say "schedule this to continue" and Daymon queues it up.

Everything runs locally. Tasks execute via claude -p "prompt" as subprocesses. MIT licensed.

Stack: Electron, TypeScript, React, Tailwind, better-sqlite3, node-cron, chokidar, MCP SDK.

Limitations: Mac only for now (Linux planned). Requires Claude CLI. DMG is ~250MB due to Electron. Early stage, solo developer. On whether Anthropic will build this natively: Probably, eventually. But their consumer model relies on session limits to push users from Pro to Max. Native scheduling would undermine that — if Claude can queue work across your limit window, there's less pressure to upgrade. Your subscription sits idle every time you close the tab, and that idle time is arguably working as intended. Daymon exists because I don't think you should have to wait for them to figure out their incentives.

Would love feedback on the architecture and what you'd want to see next.