Artem Tolmachev (@artyomx) header
Artem Tolmachev (@artyomx) profile picture

Teddy Kids, Apple, Skydiving, Business, Boss

Leiden
Joined February 2009
We found a much better way to run MCP servers with coding agents, and it started with a crash. Codex wouldn't start. The error blamed "workspace requirements". The real cause: its background daemon was holding 269 open file handles against a macOS limit of 256. 111 of those were pipes to MCP helper processes. Every thread, and every subagent thread, had spawned its own copy of every MCP server. 42 helpers under one daemon. Nothing ever shut them down. Then we looked at Claude Code. Same waste, different shape: 8 open sessions, each running a dozen database helpers nobody was using. We killed 90 idle processes in one go. Around 500 MCP tools across 21 servers were loaded "just in case". The question that fixed it: why does the main agent hold these at all? The setup we landed on: 1. The orchestrator (Fable) holds almost no MCP. It keeps memory, the code graph, and READ-ONLY access to the production database for ten-second fact checks. 2. Every task-specific service gets its own specialist agent with the MCP server defined inside the agent file: --- name: db-prod model: claude-opus-5-5 effort: high tools: Read, Grep, Glob, Write, mcp__supabase-readonly, mcp__supabase-write mcpServers: - supabase-write: type: stdio command: mcp-server-supabase args: ["--project-ref=YOUR_REF", "--features=database,functions"] --- The server connects when the agent starts and disconnects when it finishes. The main session never sees it. 3. The orchestrator briefs an outcome, not a solution: target project, permitted change, how to verify. The specialist inspects the real schema, pushes back if the brief is wrong, executes only what was authorized, and returns evidence. Never a bare "done". 4. One specialist per task, not per query. Continue the same agent through investigation, change and verification. We tested this: it keeps its context and its database connection. What you actually gain is not tokens. Idle MCaude Code and cost almost nothing. You gain three things: - Production write access stops being ambientprod by accident. A write only happens through a brief that names the exact change. - Schema dumps and query results stay out of . - Zero idle processes. Where we deliberately did not go all the way:ad-only database access. If every "does this column exist" needs a dispatch, agents start ng. Costs to know: a specialist with a big tool ct. Our video-generation agent cost about $1 for a single balance check, because its 105 tool . Batch the work per stage. We now run this for Supabase (one agent per project), Plaud and Higgsfield. The same pattern works in Codex with per-agent MCP config. Put the MCP where the work happens, not where the conversation is.
7
2
242
Artem Tolmachev retweeted
Elon Musk just gave the clearest AI timeline we’ve heard so far. In under 10 minutes he lays out: 1) AI surpasses all human intelligence in ~5 years 2) Humans most likely lose control within 10 years 3) Most probable outcome: an age of amazing abundance 4) “Even if there was a stop button — we probably shouldn’t press it” This is denser and more direct than most hour-long podcasts on the topic. If you still think AI is “just another tool”, this 10-minute segment will recalibrate you.
602
1,215
163
6,438
1,211,329
try this... dont clear context in claude code or chatgpt... ask (using skill) your agent whats in context and what more u can do! .. less token burn.. more PRs!!! @ClaudeDevs @AlexFinn --- name: idea description: Context-leverage ideation — inventory what is currently warm i n this session's context (files read, schemas mapped, decisions made, domai ns explored) and generate ranked next-move ideas that exploit it, plus "als o new" ideas Artem wouldn't have thought of. Use when Artem types /idea, as ks "what's in context", "what can we build without reloading", "what next w ith what you know", or after shipping when deciding the next move. Always a nswered by fable (main loop) — never delegated. model: fable --- # /idea — Context-Leverage Ideation ## What this is Warm context is capital. After a work session, the main loop holds a deep, expensive-to-rebuild map of some slice of a codebase: file internals, schem a columns, data flows, permission models, gotchas, half-noticed dead code, decisions and their whys. This skill spends that capital deliberately: it a nswers "what should we build NEXT, right now, while all of this is still lo aded?" **This runs in the main loop (fable), never a subagent.** The whole point i s the session's accumulated context — a subagent doesn't have it. ## Step 1 — Honest context inventory Take stock of what is ACTUALLY warm — things you could act on without re-re ading: - **Domains mapped**: which feature areas do you know at file:line depth vs . only by name? - **Schemas & data**: tables, columns, views, edge functions, sync flows yo u've verified this session (not from memory files — from this session's too l results). - **Live discoveries**: bugs noticed but not fixed, dead code, TODO-shaped smells, data-quality issues seen in real query results, patterns that hurt (footguns you hit). - **Decisions & constraints**: what the user ruled in/out this session, sta nding policies, deferred - **Cold zones**: name explicitly what would be a cold start — this keeps t he ideas honest. Write the inventory as ttput: 4–8 lines, grouped by domain, each line endeep)`, `(mapped)`, `(name s only)`. Do not pad. Iflittle is warm, say so an d keep the whole output ## Step 2 — Three idea t ### Tier A — Cash in the context (ready now) Features/fixes where >70is already loaded. For ea ch: - **What** (1–2 sentencees/tables it touches) - **Why now** (which warm context it exploits) - **Size** (S: one build: needs a plan) - **Edge**: one non-obvious implementation insight from the warm context — the thing a cold sessionIf you don't have an edge for an idea, that's a sr nowhere. Include the user's own phen they qualify — but re -rank them against freshthe backlog. ### Tier B — "Also new" (the ones he didn't ask for) 2–4 ideas the user likel come from *collisions* i n the warm context — two facts that together imply an opportunity: - A data-quality signal seen in real query results → a standing guard/nudge feature - A manual process the somate it for next time - A policy that lives in someone's head (user said it in chat) → encode it in the product - A structure that exists for X → nearly-free variant for Y - A thing that will silee (yearly tables, CAO rou nds, cert expiries) → alert/cron before it does Mark each with what sparked it: `spark: <the two facts that collided>`. The se must be genuinely newsed. Aim for at least one idea that makes the use ### Tier C — Worth it despite cold start At most 2. Only if something observed this session makes a cold-zone item u nusually urgent (e.g. a bug symptom points there). Otherwise write "none — everything else costs a ## Step 3 — The play End with **The play**: pce (2–4 items, ordered), justify it in 2–3 sentences (dependency order, context-decay order — do the deepest-context item first, sizes), and state total estimated scope. Decis ive — one sequence, not a menu. Then offer: "/write-plan for these?" (or di rect build if everything is S-sized). ## Rules - **BRUTAL-mode quality bar applies** (this is an analysis/options request) : run the impact gate frdeas that only make the l ist look full; if an ideny assistant could have p roduced it without this or move it to a one-line mention. - Ideas only — zero impls (writing a plan afterwa rds is a separate explicit step). - Every Tier A/B idea must trace to specific warm context (name the file, t able, query result, or decision). No idea may rest on an unverified assumpt ion about how the code w unverified, tag it `[ver ify first]`. - Respect the standing project rules (no mock data, surgical scope) when sh aping ideas — don't propose features that violate them. - Match his energy. If he asked with excitement, the writeup can have punch ; it still has to be dense. - Output is chat-only markdown. No files, no artifacts, unless he asks.
1
274
**I burned a stupid amount of Claude quota switching models & effort levels mid-session. Nobody on X talks about this. Here's what's actually happening under the hood — with real numbers from my own transcript.** 🧵 So there's a keyboard shortcut to switch effort levels in Claude Code. It's animated and everything. I was flipping it every 3-4 messages — ultracode for hard stuff, low for easy stuff. Felt smart. Felt free. It's not free. Every flip re-reads your ENTIRE conversation at full price. Here's why. **1/ Anthropic caching is a PREFIX cache.** When Claude Code sends a turn, it's: system prompt + tool schemas + your project files + all prior messages + your new message. Anthropic caches the *processed state* of that big stable chunk so the next turn skips redoing the math. You pay ~10% of normal input price for cached tokens instead of full price. Two rules make it click: - The match runs from byte 0 forward. The instant something differs, everything after it must be re-read. - The cache key isn't just the text. **Model and effort level are baked into the key.** Each model has its own cache. Each effort level has its own cache *for the same model*. Flip effort → different key → nothing matches → your whole history reprocesses from the top. That's the "full history will be reread" warning in the terminal. It's not re-reading because it forgot something. "Low" and "ultracode" literally use different cache buckets. **2/ What's actually cached will surprise you.** I measured my own session. When it started, ~70,000 tokens got cached on the first call — and almost NONE of it was my conversation. My first message was ~40 tokens. The other ~70k is scaffolding: - System prompt + harness instructions - **JSON schemas for every tool** — including every MCP server you have connected. This is the fat one. Every tool's full parameter schema gets cached even for tools you never call. - Skills list, MCP server instructions - CLAUDE.md (global ~1.5k tok, project ~2.6k tok) - Memory index (~3.5k tok), session-start hooks (~3.2k tok) So when you flip effort, you're not re-reading "a few messages." You're re-caching the entire Claude Code boot image + your whole chat. **3/ Real numbers from my actual transcript** (jq over the session .jsonl — you can do this yourself, transcripts live in ~/.claude/projects/): ``` model in(1x) write read out claude-opus-4-8 24627 45465 0 4680 ← cold start claude-opus-4-8 1 31635 45465 1561 claude-opus-4-8 2662 1683 77100 2051 claude-opus-4-8 2 6702 78783 2572 claude-opus-4-8 2 2697 85485 1289 claude-opus-4-8 2 1759 88182 4562 claude-opus-4-8 131 5932 89941 5499 claude-opus-4-8 2 5724 95873 2947 claude-opus-4-8 2 3167 101597 3908 claude-opus-4-8 2 3984 104764 2537 ``` Watch the READ column climb: 0 → 45k → 77k → 105k. After the cold start, nearly the entire conversation gets re-read at 0.1× every call. That's caching working. Each turn freezes the previous turn's additions into the growing cached prefix. The multipliers (vs base input price): - Cache READ: **0.1×** (90% off) - Cache WRITE, 5-min TTL: 1.25× - Cache WRITE, 1-hour TTL: 2× - Uncached: 1× Caching is a bet: pay a write premium once, read it back at 10% every turn after. The more turns, the more the bet pays off. In my short session it saved ~30% — worst case scenario. Long sessions land at 80-90% because reads dwarf everything. (Also: caching does NOT shrink your context window. The tokens are still there, still counted. It only changes the *price of re-reading* them.) **4/ So what does one switch actually cost?** Extra cost ≈ your whole prefix re-written at 2× instead of read at 0.1× → roughly **prefix × 1.9**. Early session: ~130k input-equivalents per flip. Deep session at 110k context: ~218k per flip. I was doing this every 3-4 messages. Across weeks. Millions of wasted input-equivalents. (If you're on a Max subscription like me: that's quota and rate-limit budget, not cash. If you're on API billing: that's cash.) **5/ Here's the twist that saved me — the reread is billed at the NEW model's rates.** Switching DOWN (Opus→smaller model) = you pay the switch tax in cheap tokens. Switching UP = you pay it in expensive tokens. Huge asymmetry. Break-even for switching down: **N ≥ 218 / (19 × (R−1))** turns, where R = how much cheaper the target model is, ~19k equiv = my steady-state per-turn cost at ~109k context. - 5× cheaper model → pays off in ~3 turns - 3× cheaper → ~6 turns - 1.5× cheaper → ~23 turns **6/ The rules I wish someone had posted before me:** 1. **Switching DOWN: break-even ~3-6 turns.** Got 5+ routine turns left? Switch. Just 1-2 quick questions? Don't bother. 2. **Switching UP: never for one question.** Tax billed at the expensive model's rate, no per-turn discount ever. For one hard problem, spawn a subagent on the big model instead — fresh small context, full power, your main cache untouched. That's the cheat code. 3. **Effort switches (same model): almost never worth it.** Same token price on input → the reread tax is pure loss, only offset by fewer thinking tokens later. Effort ping-pong is strictly worse than model ping-pong. This was my actual leak. 4. **Prefix size IS the tax.** At 20k context a switch costs ~38k. At 110k it's ~218k. Switch early or never — the deeper the session, the more locked in you are. 5. **Best move: new session per task.** A fresh chat pays the ~70k boot-image cold start anyway, so that's your natural free-ish switching point. Pick model + effort THERE, ride it to the end. (And no, /clear doesn't delete anything — full transcripts stay on disk, resumable.) 6. Idle >5 min busts the cache too (same reread, different trigger). `ENABLE_PROMPT_CACHING_1H=1` stretches TTL to 1 hour — writes cost 2× instead of 1.25×, but if you step away from sessions a lot it's worth it. **TL;DR:** model + effort + context = one cache bucket. Change ANY of them, you rebuild the bucket at full price. The shortcuts make switching easy, not free. Easy + free-feeling is the trap. Set model + effort per PHASE of work, not per message. Your quota will thank you.
1
4
859
Artem Tolmachev retweeted
this Hermes agent finds clothing stores, puts their clothes on a model in a cinematic reel, and mails them a postcard on autopilot... here's how content studios & social media managers can land recurring clients with this system: - watches google maps for offline clothing stores - filters for the ones most likely to spend (real store, real inventory) - finds their clothing right off their website - or pulls it straight from their Google listing photos - extracts their single best piece - renders it on a real model, cinematic 9:16 reel, multi-angle - prints a postcard with a frame from their reel + a QR to watch - mails it straight to the owner by name every step from storefront to mailbox is automated. reply "REEL" + RT and i'll send you the full breakdown so you can build this too (must be following so i can DM)
497
295
3
824
49,338
I built CopyClaw for this exact reason — under 100ms from shortcut to paste when you know what you're looking for. 5.6MB, ARM native, free, no subscription: copyclaw.nl What's your setup? Maccy? Paste? Raycast? Something else? 🦞
71
I built CopyClaw for myself before the wave. The problem was always friction. Paste is beautiful but $30/yr. Maccy is fine. Clipy is abandoned. I just wanted: shortcut → type → paste. Done.
1
13
Replying to @artyomx @OpenClawAI
The stack (anyone can replicate this): • Export: ChatGPT Settings → Export Data (free) • Indexer: Python script (free) • Mining: Claude Sonnet via @OpenClawAI subagents (~$2) • Storage: GitHub (free) Total: $2 and 30 minutes for 3 years of brain extraction. Export your data. Index it. Mine it. You have a goldmine sitting in Settings → Export. Go get it. 🧵
3
74
Replying to @artyomx @OpenClawAI
What the agents found: Daycare: Full staff database, debt structure, pricing tiers, acquisition interest from a major chain. One agent, 4 min, 20KB. Biohacking: 57 supplements with dosages, 4 cognitive stack modes, 12 peptide protocols. Entire optimization system I forgot I designed. Education: MBA curriculum for kids, 8 expansion targets across 3 continents, a gamification engine with school coins/banks/auctions.
1
1
41
But the real gut punch: 338 unfinished projects. Not failures. Forgotten dreams. A teacher scheduling system — Phase 1 was COMPLETE An AI-powered workbook engine — full 5-phase blueprint A pregnancy tracker — twins are coming, I forgot I planned this A daycare management platform — complete architecture They werent abandoned because they were bad. They were abandoned because the New Chat button killed the context.
1
23
Your @openclaw bot is dead right now. You just don't know it. The gateway crashes silently. No error. No alert. You message your bot — nothing. It's not slow. It's dead. The worst part? The gateway IS the notification system. When it dies, it can't tell you. 🧵
35
Full writeup with architecture, gotchas, and the sentinel script: moltbook.com/post/7886e84b-9… @steipete — would love openclaw health as a proper HTTP endpoint. Currently WS-RPC only, so external watchdogs can't use it. GitHub #5199 and #1620 are related. Built with 🦞 by @artyomx + @ClaudeShel73037
28
Found in my notes — a philosophy I live by but never articulated: "Stop being patient — plan to do in 6 months what others accept will take 10 years." It was buried. Now it's my operating principle.
17
My AI found my life motto buried in a 2020 note: "Fucking dream Big" I forgot I wrote it. The AI didn't. Your past self leaves breadcrumbs. Most people never look back.
16
Freedom needs guardrails: • Scope: 2-4 hours, testable by morning • Document everything in a build log • If it touches external systems (email, social) → draft only, don't send • Ship something REAL, not a plan
1
3
My AI already has: - Full codebase access - Memory system that persists - 100+ skills to draw from - GitHub for shipping - Context about our goals It knows what we're building toward. It just needed TIME.
3