WhatsApp MCP on Cloudflare

Someone built an MCP server that connects Claude Desktop (and other MCP-compatible AI tools) directly to WhatsApp. The server runs on Cloudflare Workers, so you don’t need to host anything yourself.

MCP is Anthropic’s Model Context Protocol, the standard that lets AI assistants talk to external tools and data sources. This implementation means you can now ask Claude to send WhatsApp messages, check your chats, or automate messaging workflows without leaving your AI interface.

The Cloudflare deployment is the interesting part. Most MCP servers require you to run a local process or manage a server somewhere. This one leverages Cloudflare’s edge network, which means it’s free to run (within Cloudflare’s generous free tier) and has near-zero latency globally.

Setup involves connecting your WhatsApp account through the WhatsApp Business API, then pointing your Claude Desktop config at the Cloudflare Worker endpoint. From there, it’s standard MCP stuff: Claude can list conversations, read messages, send texts, and manage contacts.

Who should care: Anyone building AI workflows that need to touch messaging. Customer support automation, notification systems, or just personal productivity setups where you want Claude to handle some of your chat grunt work.

Who can skip it: If you’re not using MCP-compatible tools or don’t need WhatsApp integration, this won’t change your day.

Superlite vs Superpowers

Superlite is positioning itself as a faster alternative to Superpowers, the AI agent framework that’s been making rounds in developer circles.

The pitch: hand an AI agent a spec, get working code faster. Superlite claims speed improvements by stripping out some of Superpowers’ overhead and focusing on the core loop of spec-to-implementation.

Superpowers has been popular for building agentic workflows where you describe what you want and the agent figures out the implementation. Superlite argues that framework got too heavy. Their approach keeps the same general idea but cuts the processing time.

Concrete benchmarks would be helpful here, but the core argument is sound. If you’re running dozens of agent iterations per day, shaving seconds off each cycle adds up.

Worth trying if: You’re already using Superpowers and hitting performance walls, or you’re starting fresh and want something lean.

Not urgent if: You’re happy with your current agent setup or not building agent workflows at all.

Tmux for AI Agents

A new guide on using tmux with Claude Code tackles a specific pain point: AI coding assistants often struggle with long-running processes and session management.

The problem: when Claude Code (or similar tools) runs a command, it expects a quick response. Long builds, dev servers, or test suites that run for minutes don’t fit that model well. The agent sits there waiting, burning through context, or worse, times out and loses track of what it was doing.

The solution: tmux sessions. Spin up persistent terminal sessions, send commands via tmux send-keys, and let processes run in the background. The agent can check back later, grab output from the session buffer, and keep working on other tasks while compilation happens.

The guide covers the specific send-keys patterns that work well with AI agents, how to name and manage multiple sessions, and how to handle the “ceiling” problem where tmux’s scroll buffer fills up and you lose early output.

This is practical stuff. If you’re using Claude Code or similar tools for anything beyond toy projects, you’ve probably hit this. The tmux approach won’t solve every problem, but it’s a solid pattern for managing async work in an AI coding workflow.

LLM Proxy Monitoring

A blog post making the rounds argues that if you’re building on LLMs seriously, you need to run your own proxy layer.

The argument: without a proxy sitting between your application and OpenAI/Anthropic/whoever, you have no visibility into what’s actually happening. You don’t know token counts, latency patterns, error rates, or cost breakdowns in real time. You’re flying blind.

Fair point. If you’re shipping an LLM-powered product, that visibility matters. A proxy layer gives you metrics, logging, rate limiting, failover, and cost controls all in one place.

Tools like LiteLLM, Portkey, or self-hosted solutions give you that layer. The tradeoff is operational complexity. You’re adding another service to monitor, another thing to keep running.

For side projects or early prototyping, probably overkill. For production stuff with real users and real bills, hard to argue against it.