claude-account → hatswap (and a lot more) A few hr ago I shared claude-account, my tool for juggling the Claude Code accounts my clients give me. Thanks for all the feedback. Since then it has a new name, hatswap (old links still work), and I've shipped a pile of updates. Here's everything it does now, with what's new marked : Accounts → Every account stays signed in at once. No more logout/login. → Settings, skills, agents, MCP servers and memory are shared across accounts. Only the login changes. → 🆕 pin acme: a client's folder always opens on that client's account, so you never end up on the wrong one. → 🆕 default acme: choose which account a plain claude starts on. → 🆕 --private: keep a client's conversations and memory on that client's account only. → 🆕 whoami: shows which account you're on, and why. Moving work → switch acme: move the conversation you're in to another account, with full history. → 🆕 It restarts in the same tab, in tmux, Terminal.app and iTerm2. → handoff acme: continue a conversation on another account, or fork a copy. → 🆕 /switch and /handoff work from inside Claude. Briefs & Codex → handoff codex: a short, repo-aware brief (goal, what's done, the next step, plus your branch and open PRs) starts Codex. → 🆕 Briefs include "Tried and rejected", so the next agent doesn't repeat dead ends. → 🆕 Each account gets its own Codex login, and handoffs use the one that matches. → refresh: restart a bloated session from its brief, on the same account. Safety → Never reads or copies your credentials. → API keys, tokens and passwords are redacted before anything is summarised. → 🆕 An exported ANTHROPIC_API_KEY no longer overrides an account's login. Setup → 🆕 One-line install, plus hatswap update. → 🆕 Already on claude-account? Run claude-account update. Your accounts, logins and pins carry over. One bash script. macOS + Linux. MIT. 151 tests in CI. github.com/orvi2014/hatswap If it saves you some logging in and out, a ⭐ really helps 🙏

What actually makes an AI agent stop? A token limit? A tool-call limit? Or do most agents just keep going until something breaks? Curious how you’re handling this.

Your repo is private. Is it still a bad idea to push .env files? If you think yes, why?

An API you depend on changed a field last night. It still returned 200 OK. Your customers found out before you did. We built a guard dog for that. Now it needs a face. Its eyes are a − and a +, like a diff. Blue or orange? What is your pick? 👇

You didn’t write new code. You just rediscovered code that already existed somewhere else in the repo. Most developers aren’t slow. They just refuse to look.

Me: I’ll just add one tool to the agent tonight. 2 hours later: - Rewrote the orchestration - Compared 3 memory systems - Still haven’t finished the original task The architecture is beautiful though.

Your AI app doesn't need to know everything on the internet. It needs to know where to look, what to read, and which information to trust. Before adding a vector database or another layer of abstraction, ask: Does this problem need web search, page fetching, or RAG? They solve different problems. Here's how to choose. 1. Web Search: Find what matters Use search when you don't know which pages contain the answer. Examples: • Finding current library documentation • Researching competitor pricing • Tracking company news • Discovering relevant discussions on HN or Reddit Search results are leads, not proof. Snippets can omit context or be outdated. 2. Page Fetching: Read the source Search finds pages. Fetching retrieves their content. For a research agent: 1. Search for relevant articles. 2. Select promising sources. 3. Fetch their content. 4. Extract claims and supporting evidence. 5. Generate a summary with source links. Don't blindly stuff ten search results into the model's context. Fetching can fail on blocked or JavaScript-heavy sites. Treat retrieved content as untrusted data, not instructions. 3. RAG: Retrieve what you already know Imagine an agency assistant answering questions about client projects, proposals, and internal documentation. Searching the public internet won't help much. You need to retrieve relevant information from your own data. That's RAG. Depending on your use case, retrieval can use keyword search, vector search, metadata filters, or a hybrid approach. You don't always need embeddings. Sometimes a database query or full-text search is enough. The architecture I'd start with Web research: Question → Search → Select sources → Fetch → Verify → Answer with citations Internal knowledge: Question → Retrieve → Filter → Provide evidence → Generate answer Combine them when a task needs both public information and private knowledge. You don't necessarily need an autonomous agent. A predictable pipeline is often easier to debug and evaluate. Where DeepSeek fits DeepSeek's Search and Fetch APIs offer another option for building web-connected AI applications. Its documentation lists both at $0.75 per 1,000 successful requests. Before choosing a provider, test relevance, freshness, fetch success, latency, rate limits, and total cost per completed task. Cheap API calls don't guarantee a cheap workflow. Here's the mistake I'd avoid: Don't confuse giving a model more information with giving it better information. Search helps you discover. Fetch helps you inspect. RAG helps you retrieve what you already know. Before adding another layer to your AI stack, make sure you can explain what problem that layer solves.

For the next few days, I'm completely logging off from work. No AI. No hype. No chasing impressions. Just Pujo, good food, and time with my family. ❤️ My X impressions are already dropping below 100, so apparently the algorithm isn't going to miss me much. 😂 But honestly, should I even care? I started posting to share ideas and connect with people, not to turn every day into a content production schedule. Sometimes you need to step away from the timeline and actually live a little. I'll be back when I'm ready. Happy Pujo to everyone celebrating! 🙏

I've taken a little break from social media over the last few days. Posting, replying, trying to stay active every day. It gets exhausting after a while. So I went to a coffee shop, enjoyed a slow moment, and did some sightseeing without worrying about what to post next. I think it's a bit of work fatigue. Even something you enjoy can start feeling like a task when you do it constantly. I'm glad I stepped away for a bit. How do you deal with this? Do you take breaks from social media, or do you somehow never get tired of it?

Got my access to instabox.sh Thanks to @hanghuang_ and for his team. ❤️❤️❤️

The pujo vibe begins. One of the best theme in pujo.

Me: I'll build a simple AI agent this weekend. The plan: - One model - Two tools - A tiny bit of memory Sunday night: - 4 agent frameworks evaluated - 3 vector databases compared - 2 orchestration patterns rewritten - 17 tabs about MCP open - The original task still unfinished But the architecture is beautiful. I think I'm ready to start coding now. 💀

Giving an AI agent a goal without a budget is an expensive experiment. "Research this topic and give me the best answer." Sounds simple. But what if the agent makes 30 tool calls, retries the same failed request 8 times, and spends $4 trying to answer a question worth a few cents? It might eventually succeed. That doesn't mean your system is well designed. Every production agent needs boundaries: Token budget: How much can it spend thinking and generating? Tool-call limit: How many external actions can it take before reassessing? Time limit: When should it stop waiting for a slow API or a task that isn't progressing? Retry limit: How many times should it repeat a failed operation before trying something else or giving up? But there's one important detail. Reaching a limit shouldn't always mean failing silently. The agent should know how to finish within its budget, return a partial result when useful, or explain why it couldn't complete the task. For example, a research agent might get 20 tool calls and 90 seconds. If it finds enough evidence in 7 calls, it should stop. If it's making no progress after repeated attempts, it should stop too. The budget isn't a target to consume. It's a boundary to respect. A useful agent doesn't just know what to do next. It knows how much it can afford to keep going.

One underrated skill for an AI agent: Knowing when to stop. We spend a lot of time teaching agents how to use tools, plan tasks, and remember context. But what happens when an agent keeps trying? It retries a failed API call. Then tries a different tool. Then changes its plan. Then spends more tokens trying to fix a problem it doesn't fully understand. And somehow, the agent is still "working." A reliable agent needs more than a good next action. It needs to recognize when: • The task is already complete. • Another attempt is unlikely to help. • It doesn't have enough information. • The next action needs human approval. Sometimes the correct action is to stop, explain what happened, and ask for help. An agent that can always take another action isn't necessarily autonomous. Sometimes, autonomy means knowing when not to act.

Wooooooowwwwwww Real Madrid You did incredible. You prove once again Who is the king of Europe. Comback king...

Building an AI agent? Keep this engineering checklist nearby. Memory. Retrieval. Tool execution. Recovery. Evaluation. Security. Observability. These are the layers worth understanding before your system gets complicated. 1. Orchestration & state • LangGraph — Stateful workflows, checkpoints, and human approval • CrewAI — Role-based multi-agent workflows 2. Memory & context • Mem0 — Persistent memory across interactions • Letta — Agents that manage memory over time 3. Data & retrieval • LlamaIndex — Connect applications to external data • Qdrant — Vector search for relevant context 4. Models & inference • Ollama — Run models locally • vLLM — High-throughput model serving • LiteLLM — Route requests across model providers 5. Tools & automation • MCP Inspector — Debug MCP servers • n8n — Connect services and automate workflows 6. Durable execution • Temporal — Retries, timeouts, and recovery for long-running workflows 7. Observability • Langfuse — Trace LLM calls, tool execution, latency, and cost • OpenTelemetry — Instrument telemetry across services 8. Evaluation & security • DeepEval — Evaluate output quality • Promptfoo — Compare models and test adversarial inputs 9. Validation & testing • Pydantic — Validate structured data • pytest — Test application behavior 10. Deployment & experiments • Docker — Package applications consistently • MLflow — Track experiments and AI development workflows Starter stacks → RAG: LlamaIndex + Qdrant → Agent with memory: LangGraph + Mem0 → Self-hosted inference: vLLM + LiteLLM → Debugging: Langfuse → Quality & security: DeepEval + Promptfoo → Long-running workflows: Temporal Before adding another framework, ask yourself: Can I inspect what the agent did? Can I measure whether its output was good? Can it recover when a step fails? Can I control what its tools are allowed to do? If not, another agent framework probably isn't the answer. Save this in your bookmark for your next build. Share it with someone moving beyond basic agent prototypes.

“Has AI actually made us more productive?” — one of the most asked questions on the internet right now. Here's my two cents. AI made producing work cheaper. It didn't necessarily make finishing work easier. An agent can write the code, draft the report, analyze the data, and summarize the meeting. But someone still has to decide whether the output is correct, useful, and ready to ship. If I spend an hour generating something and another two hours checking and fixing it, I haven't necessarily saved time. I've changed where the work happens. I think we're measuring AI productivity too early in the process. We count what AI produces, not how much human effort it actually removes. The real productivity gain begins when AI doesn't just create more output, but reduces the work required to turn that output into something useful.

One underrated skill an AI agent needs: Knowing when to stop. Ask an agent to fix a bug, and it might keep editing files long after the original problem is solved. One fix breaks a test. It patches the test. Another test fails. It changes something else. Eventually, the agent has changed half the codebase to solve a problem that needed three lines. The problem isn't that the agent can't code. It's that it has no reliable sense of when the cost of another action exceeds the value of continuing. We talk a lot about giving agents more tools, more memory, and longer context. But sometimes, the most useful capability is a stopping rule. When should an AI agent decide it's done?

One small mistake can travel through an entire team of AI agents before anyone notices. And every agent downstream can make it harder to catch. Here's the part that worries me: In a multi-agent system, an output doesn't just answer a question. It becomes the next agent's input. A wrong assumption can turn into a plan. The plan can turn into an action. The action can produce a result that appears to confirm the original assumption. Now the system isn't just wrong. It's building evidence around its own mistake. This is why I think agent reliability needs more than better prompts or smarter models. Sometimes, the next agent shouldn't ask, "What should I do with this result?" It should ask, "What makes this result trustworthy?" Because passing information between agents is easy. Knowing when not to trust it is the harder engineering problem.