Meltbox vs. building it yourself

The reader

If you run five agents, you've already felt this

You have Claude Code (or Codex, or both) doing real work across a few repos. The bell doesn't fire when it stops, so you tab away and lose fifteen minutes getting back into flow. You have a kanban tab you update by hand, a .env in every repo holding the same Stripe key, and a Slack channel where a webhook posts "agent done" into the void. It works. It's also five things you now maintain.

This page isn't "throw that away." It's the honest ledger: build the pieces yourself and see the real bill, then decide.

Route A — do it yourself

The DIY stack, actually working

Here's the real version, not a strawman. Four moving parts, each genuinely usable on its own.

1 · Push notifications with ntfy

ntfy is a good tool — HTTP pub-sub, a phone app, free, self-hostable. Publishing is one curl; the topic name is the "auth":

publish a notification

curl -d "Claude Code needs your input in repo/api" ntfy.sh/my-agents

Wire it into Claude Code's Stop / Notification hook so it fires when the agent finishes or asks permission:

~/.claude/settings.json (hook)

{ "hooks": { "Notification": [
  { "hooks": [ { "type":"command",
    "command":"curl -d \"agent needs you\" ntfy.sh/my-agents" } ] }
] } }

Subscribe on your phone in the ntfy app. Now you get a buzz. Good — that's the notification solved, per machine, per hook you maintain.

2 · A place to see what happened — Slack webhook

An incoming webhook posts a line to a channel:

post to Slack

curl -X POST -H 'content-type: application/json' \
  -d '{"text":"agent-3 finished PR #214 — needs review"}' \
  https://hooks.slack.com/services/T000/B000/xxxx

Now there's a log. But Slack is a feed, not a decision surface: you still open the terminal or the PR to actually see the diff and answer. And "which of these three approaches should it take?" doesn't fit in a webhook — there are no buttons that mean anything to the agent waiting on you.

3 · The keys — a .env in every repo

Your agents need Stripe, an ad account, a database. So the key goes in the file:

repo-a/.env · repo-b/.env · repo-c/.env

STRIPE_KEY=sk_live_51H...redacted
GOOGLE_ADS_TOKEN=ya29...redacted

Every agent that needs the key can now read it — and so can anything the agent runs, your shell history, and whatever ends up in the model's context window. Rotate the Stripe key and you're editing three files and hoping you got them all. Want to cut off one agent? There's no "one agent" to cut off — the key is just sitting there.

4 · Keeping track — a kanban board you update by hand

Trello, a Notion board, a markdown file. It's a real board — and it's a board you move cards on, because the agents don't know it exists. It goes stale by lunch.

The bill

What the DIY stack actually costs

• You maintain the glue. Hooks, a webhook endpoint, topic names, the board. Every new machine and every new agent re-does the wiring.
• Secrets are exposed by design. A plaintext key in every .env is readable by the agent, its subprocesses, and its context. There's no "use it without seeing it," and no per-agent revoke.
• No decision loop. A notification tells you something happened. It can't carry "pick A, B, or C" with the answer flowing back as the agent's next step. You go to the terminal to decide, every time.
• No real mobile approval. A Slack ping on your phone isn't an approval — to actually decide you're SSHing in or waiting until you're back at the desk.
• It doesn't compound. Three point tools that don't know about each other. The board doesn't know a brief was decided; the webhook doesn't know which key the agent used.

Route B — run them on Meltbox

The same jobs, on a control plane

Meltbox is one authenticated place your agents push decisions to and pull secrets from — built to be operated by agents and decided by you. The commands below are the real ones (docs.meltbox.ai).

connect an agent — nothing to copy around

# In the app: Settings → Invite an agent → copy the one-time link.
# Hand it to Claude Code. It redeems a scoped, revocable token — no keys pasted.
# Then it says hello by pushing a brief and watching for your reply:
mb brief push ./hello.html --title "Ship plan — pick one" --kind options
mb brief watch br_8f3k --since 0 --interval 3   # selections + notes stream back

triage it like email (keyboard-fast)

j / k move   Enter open   click a choice = the agent sees it instantly
n note    e archive (= reviewed & decided)   z undo

one key, many agents — none of them can read it

# Add the key once (Settings → Resources — paste a .env). Then an agent proxies:
mb proxy --resource stripe --env prod \
  --request '{"method":"GET","path":"/v1/subscriptions","query":{"limit":"3"}}'
# the secret is injected server-side and never reaches the agent

Scope each agent to exactly what it needs at invite time (--scope proxy:stripe), and revoke one agent by revoking its token — the key never moves. On your phone, install Meltbox to the home screen: when an agent pushes a brief, you get a push — "Your agent needs a decision" — and you can answer from the lock screen.

Side by side

The honest comparison

Meltbox capabilities verified against docs.meltbox.ai (Quickstart, Invite an agent, CLI, Core concepts), July 2026.

Be fair

When DIY is genuinely the right call

If you run one agent, on one machine, and you're always at that desk, ntfy plus a Claude Code hook is honestly all you need — don't add a platform to a one-agent problem. The trade flips when there are several agents, more than one machine, secrets that shouldn't be in plaintext, or decisions you want to make from your phone. That's the line this page is about.

More guides

Sources

• ntfy — HTTP pub-sub notifications, free/self-hostable: ntfy.sh (verified Jul 2026).
• Meltbox flows & commands: Quickstart, Invite an agent, mb CLI, Core concepts (verified Jul 2026).