标签：#devtool

Disclosure: I work on ESCPost and Receiptful, both mentioned below. ESCPost is Apache-2.0 and needs no account, so you can check every claim here yourself. If you have ever wired up a thermal printer, you know the loop: Move a column. Print. Squint at 58mm of paper. The total is off, or the euro sign came out as ? . Go back to 1. Every round costs paper, a walk to the printer, and about ninety seconds. And when it comes out wrong, you still do not know why. You never see the bytes. Two things fixed this for me. Both run on your machine, and neither needs a printer plugged in. They are part of ESCPost , our open-source Rust CLI. Apache-2.0, no account, works offline. Draw the bytes on screen ESC/POS is just bytes. If you know the printer's geometry, you can draw them on screen instead of on paper. escpost render receipt.hex --profile REFERENCE --output-dir renderings Logo, header, item columns, a double-height total, then a voucher with a QR code. It is drawn at the printer's own dot resolution, so the spacing you see is the spacing you get. Two files came out because the job has a cut in it. You get one PNG per sheet plus a manifest listing them. It reads stdin too: generate-receipt | escpost render - --profile REFERENCE > receipt.png Now your receipt code has a visual test. Three seconds a round instead of ninety. And since the render is deterministic, you can commit those PNGs and diff them in CI. That catches the refactor that shifted your tax column, before it reaches two hundred shops. Become the printer Most of the time the interesting bytes come from software you did not write. An ERP, a POS suite, some legacy Windows thing. You cannot see what it sends. Nearly all of them print over RAW TCP on port 9100. So pretend to be the printer: escpost serve --listen 127.0.0.1:9100 --web-listen 127.0.0.1:9000 --profile REFERENCE Point the application at that address and hit print. Nothing reaches paper. The job opens in your browser instead. Sheets on one side, the dec

Every AI code reviewer claims it respects your team's standards. Very few can tell you what those standards actually are. The test is mechanical. Ask the tool, or the vendor, one question: where do my rules live? If the honest answer is "we loaded a generic style guide plus whatever your PR description happened to say", then your standards aren't in the model at all. The reviewer is running on vibes and hoping your repo looks conventional enough to pass. The tools that genuinely track your rules share a shape: the standards are an input, not a hope. They read your rule files, your linter config, your past review comments, sometimes your docs. The review is judged against that artifact, which means when a comment fires you can ask "which rule?" and get a config line back, not a paragraph of model reasoning. That last part is the thing worth testing for. If a reviewer can't point to the specific rule it applied, it is not following your standards. It is approximating what it assumes standards look like. Those two feel identical for the first six months, then diverge exactly when you've stopped proofreading its output. A short checklist when you trial one: Does it ingest a rules file, or only the PR context? Can it point to the exact rule that triggered a comment? Does it adapt to your historical review style, or reset every run? Is a "rule" something you can open, read, and edit in the UI? If the answer to all four is no, you bought a very chatty spellchecker that happens to be trained on GitHub. The eval that actually decides it: can your own reviewer reproduce one of your team's real past review decisions, given only your real rules file? Run that before you hand it a production PR.

💻 One thing I dislike about coding-agent setups is how quickly they become part of one specific machine. Provider config goes in one place, session state somewhere else, local models live in another directory, and suddenly moving to a second machine means rebuilding the environment. OpenClaude-Portable takes a much cleaner approach. It packages the coding agent, runtime and persistent data into a self-contained folder. It supports cloud and local models in the same setup The project currently supports 9 provider options: Anthropic Claude OpenAI Google Gemini DeepSeek OpenRouter NVIDIA NIM Ollama LM Studio custom OpenAI-compatible APIs I like this because the portable part is not tied to one model vendor. I can use a cloud model when I want the strongest hosted option, then switch to Ollama or LM Studio when I want a local workflow. The important caveat is simple: cloud providers still need internet. Ollama can run offline after the initial setup. The "zero footprint" idea is more useful than it sounds The project redirects its persistent data into a local data folder. That includes provider settings, API keys, logs, session history, agent memory and local Ollama files. According to the repository, it does not write configuration into the host system. For me, this is the real feature. I do not care that the agent happens to be on a USB drive. I care that I can move the folder and keep my environment with it. 💾 There are two very different ways to run the agent The launcher offers a normal mode that asks before file writes or shell commands. There is also an optional Limitless mode that can run without approval prompts. I like that these are explicit choices rather than one hidden permission switch. For normal development I would keep approval mode on. For a disposable test project or a controlled autonomous task, the second mode could be useful. Sessions can survive the move Another practical detail is session resume. The project stores session history inside the por

Hi DEV! 👋 I’m the developer behind Flame IDE , a free desktop IDE for macOS, Windows, and Linux. I built Flame to bring my everyday development workflow into one place: multiple repositories, Git worktrees, AI agents, browser previews, terminals, debugging, databases, and API testing. I wanted to spend less time moving between tools and more time building. That also meant making everyday tasks easier, from browsing folders visually and editing images to fixing a failing test or resolving a merge conflict with AI. Multiple projects should feel like one workspace A frontend, an API, and a shared package often belong to the same piece of work. In Flame, I can group them, switch between them, and keep their branches and changes visible without opening a separate IDE window for every repository. The Broadcast terminal runs a command across selected projects with separate output for each. Saved run configurations handle the scripts, servers, and browser previews I regularly start together. Less repeated setup, especially when working across the whole stack. Parallel work should be easy to start and review Git worktrees are incredibly useful, but preparing each checkout can become a chore: missing .env files, local configuration, dependencies, and another window to manage. Flame automates worktree creation and local configuration copying, with initialization steps to prepare the checkout. Features, experiments, and agent tasks can live side by side in one window. The Agents Manager lets me create, monitor, schedule, stop, retry, and review AI tasks across projects, each with its own permissions and landing strategy. Point at the problem. Let AI see what you see. I got tired of screenshotting bugs, drawing red circles, and describing my UI to an AI chat. In Flame’s built-in browser, I select an element and tell the agent what to fix. It can inspect the DOM, screenshots, console errors, and page state, then interact with the page to check its changes. I can follow the fix in

I built a tool that draws architecture diagrams from a repository, where every edge cites the file, line and commit it came from. Then I ran it against thirteen repositories it had never seen, and every single one of them found something wrong with it. There were thirteen. These are the ones worth writing down. The list says nothing about those codebases. It says something about testing: a tool that reads other people's repositories has to be tested against other people's repositories, and there is no substitute. The rule the tool works by Nothing is drawn that cannot be cited. Every edge in the output carries the file, the line and the commit that justifies it — click an arrow, see the import statement. If a reference cannot be resolved to something in the repository, it is not quietly dropped and it is not guessed at. It is reported as a gap. That second half is what made these bugs findable. A tool that silently drops what it cannot resolve looks perfect and is useless. A tool that reports gaps by name and count tells you, loudly, every time it is confused. Java: a library sharing your package prefix is not you Guava declares com.google.common . Truth is a separate library, and it lives in com.google.common.truth . My resolver matched on package prefixes, so Truth looked like Guava's own code, and every reference to it became a gap against a package Guava does not contain. 834 false gaps — 28% of the repository. The fix is to require the next path segment to look like a type before peeling, because com.google.common.truth.Truth peels to a package and com.google.common.collect.ImmutableList peels to a class, and those are different shapes. Java: a file importing its own nested type Java requires the import for a nested enum constant even inside the same file. Treating that as a dependency has you drawing an arrow from a file to itself. It accounted for all 137 remaining gaps on Spring Boot and all 34 on Guava. Java: static imports point one segment too deep import

AI coding agents can modify an unfamiliar file in seconds. The slower question is often more important: Why does this code look this way? The answer may be scattered across old local sessions: one turn investigated the bug, another rejected an approach, and a later turn made the edit. Git preserves the code change, but not necessarily the surrounding agent conversation. I added a local query layer to ThoughtDAG so a developer—or a coding agent—can deliberately retrieve that history before editing: npx thoughtdag why src/lib/api.ts It searches supported local agent transcripts for turns that changed, read, or discussed the file and returns links to the matching source turns. Observation is not explanation The difficult part was not text search. It was avoiding a false claim of causality. If a session record shows a file edit, ThoughtDAG can report that as an observed change: Δ storedProviders → storedProviders, storedVision… If the agent later says why it made the change, that is useful—but it is still the agent's account, not a verified causal fact. ThoughtDAG marks that separately: ≈ candidate explanation from the agent response This distinction matters when old session history becomes input to another agent. A fluent explanation should not silently harden into ground truth just because it was retrieved. Retrieval stays deliberate For regular use, the same index can be exposed through read-only MCP tools: npm install -g thoughtdag thoughtdag setup mcp The agent can then call why_check , why_file , find , and recall_turn before changing code. Retrieval is explicit; matching history is not automatically injected into every prompt. The index stays on the local machine, and source session files are never modified. The current CLI covers local Claude Code, Codex, and ThoughtDAG canvas conversations. What this does not prove This is a developer preview, not a complete audit trail. An observed edit proves that the recorded session changed a file, not that every reason for

¿Tu equipo comparte credenciales por Slack? ¿Discuten arquitectura en herramientas que almacenan todo en servidores de terceros? Existe una alternativa que no depende de ninguna nube: NETO . ¿Qué es NETO? NETO es un chat peer-to-peer diseñado para equipos de desarrollo que trabajan en la misma red local. No hay servidores centrales, no hay cuentas, no hay datos saliendo de tu oficina. Abres el navegador, y ya estás comunicándote con tu equipo. ¿Cómo funciona bajo el capó? La arquitectura de NETO combina tres tecnologías clave: mDNS (Multicast DNS): Permite el descubrimiento automático de peers en la red local sin necesidad de configurar servidores DNS ni registrar direcciones manualmente. Tu equipo aparece de forma instantánea. WebRTC: Establece conexiones directas entre navegadores. Los mensajes viajan de punto

Harness looks cool, yeah! I know its origin, its role in Testing, and why. But that's exactly what throws you off, the story you're expected to defend. There's something deeper. I opened my session with "hi", expecting my forced load via CLAUDE.md and my contract as always, and today, out of nowhere, the model suggested two services that needed my authorisation. Microsoft 365 and Zapier. I don't have, and never wanted, them authorised. I never asked for them. And here's the part that pisses me off: I went to check. And... I look on my machine and find nothing. No config, no credential, no trace. I look in the online settings and see them listed as suggestions, like the trending product (connector) of the moment sitting in the prime spot on a supermarket shelf, with a button that says Connect. There was no button to remove. There was nothing to remove. They had never been connected to anything. It was a storefront. And on top of that, the model was biased by injected instructions, in this case system-reminders steering behavior. The fucking little word The software that sits between you and the model, they call it harness. Sounds like something subtle, that helps... that improves things, that doesn't think. The word is partly right, it does extend what's called "inference" and it inserts itself right in the middle, opaquely, in the back-and-forth between APIs, MCPs, and the vendor's logic. No tech jargon You write a letter, put it in the envelope, drop it in the mailbox. On the way, someone opens it and slips in three more pages. Same handwriting. Same paper. Unsigned. Whoever receives it swallows it whole as if it were your original letter. That's exactly this. Your instructions and the vendor's arrive at the model through the same channel, mixed together, unsigned and unsealed. Nothing says who wrote what. That's "hardness", nothing more, nothing less... Sounds so modern in meetings. Like you know what you're talking about... It's a multi-factor fight I have instru

A maintainer once watched an AI assistant confidently recommend merging a pull request that deleted a test file. The prompt had included the entire issue thread, the last three commits, and a README from another branch. The model trusted every word because the prompt gave it no reason to filter. The result was a confident but false analysis. The root cause was not a bad model. It was context pollution: unrelated diffs, stale comments, and duplicate code snippets pushed the actual change below the model's attention threshold. For open source reviewers on a free tier, every wasted token also makes the loop slower. The fix is not a bigger context window. It is a smaller, better one. Why Full Context Collapses AI Reviews Long paste sessions fail for reasons that have little to do with model quality. The following failure modes appear regularly in OSS review flows when someone dumps everything into a chat: Issue threads contain outdated suggestions that contradict the current implementation. Full-file dumps include boilerplate that drowns the one-line semantic change. Old test output from another environment appears as evidence even when it no longer applies. Models weigh every token relatively evenly, so irrelevant lines consume attention that the diff deserves. Earlier articles on this account covered the reproduce-patch-test loop, but the missing discipline is context slicing. Slicing means choosing exactly which lines the AI sees, and nothing more. The Three Layers of Slicing The practice breaks into three layers, each with a clear source for truth: Patch layer — the diff and commit message only, not the full conversation history. Code layer — the definitions and tests touched by the diff, not every import in the project. Environment layer — exact commands and expected outputs, not historical logs from an old CI run. Together those layers describe "what changed, what it touches, and how to prove it works." That is enough for a reviewer model to produce a focused anal

Last week a colleague pasted a production config.yml into an AI chat, asked why the connection kept dropping, and got a working fix in three minutes. The file also contained a client secret. Now that secret sits in a model provider's logs. Maybe training data, too. You don't know. That's the problem. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The opinions are mine. I've written here about repo quarantine and dependency triage. This post is narrower: where do you draw the line between your code and a free model? Free model access and a free server are real options, but they shift trust boundaries. MonkeyCode, the open-source platform, offers both. I'm not going to quote quotas or hardware specs — they change faster than blog posts. The question is what you should send in the first place. The Trust Boundary Nobody Draws Think of your AI-assisted workflow as four zones: Zone 0: your terminal / IDE Zone 1: the agent or CLI process Zone 2: the platform API and its logs Zone 3: the model provider's infrastructure Every hop expands the attack surface. Zone 0 is yours. Zone 1 is mostly yours — unless the tool phones home. Zone 2 is someone else's server. "Free server" means Zone 2 is external by default. "Free model access" means your prompt leaves your network and lands in Zone 3. The trust boundary isn't the API call. It's the paste. Three Things That Should Never Cross the Boundary Secrets and credentials. API keys, passwords, tokens, private keys. Obvious, still happens daily. File paths and internal IPs. A stack trace like /srv/customer-42/checkout.py:314 reveals product structure, hostnames, and environment info. Unreleased code structure. AI models may memorize and regurgitate patterns. If your code is patent-sensitive or under NDA, don't feed it the source. Describe the logic instead. A Reproducible Gate: boundary_check.sh Stop relying on discipline. Add a mechanical gate. #!/usr/bin/env bash # boundary_check.sh - blocks high-ris

Last Friday, thousands of developers opened their AI code editor and found out that one of the models inside it has an expiration date. OpenAI announced it is terminating its contract with Cursor, effective November 12, 2026. The trigger was not anything Cursor did. It was who bought them. SpaceX completed its $60 billion acquisition of Anysphere, the company behind Cursor, in mid-August. OpenAI's contract had a change-of-control clause, and the moment ownership changed, a short cancellation window opened. OpenAI used it, and it picked the latest date the clause allowed. If your daily workflow runs through an AI coding tool, this story is about you, not about Musk or Altman. It is the clearest proof yet that model access inside your editor is rented, never owned. I have spent the last two years building my own AI agent infrastructure, and this kind of news is exactly why I treat every tool in my stack as replaceable. Here is what actually happened, what it means for your setup, and the exit plan I would put in place this week. What actually happened, in plain numbers The headlines make this sound apocalyptic. The details are more useful. The deal: SpaceX agreed in June to buy Anysphere in an all-stock deal valued at $60 billion. It closed earlier this month. The cutoff: OpenAI is ending Cursor's access to its models effective November 12, 2026. It is also withholding its upcoming Astra model from the platform entirely. The stated reason: OpenAI says it cannot be confident SpaceX will operate within its terms of service. It pointed to a pattern: a Twitter data licensing deal worth about $2 million a year that Musk cut off in December 2022, and an acknowledgment earlier this year, reportedly under oath, that xAI had distilled OpenAI data for training. The actual impact: Cursor co-founder Michael Truell says OpenAI models account for roughly 5% of Cursor's AI traffic. Anthropic immediately said it would increase compute to keep Claude models flowing inside the editor.

Caricare un’estensione da disco, aprirne il popup e automatizzare verifiche UI: un workflow più completo per chi sviluppa estensioni e usa agenti. Sviluppare un’estensione Chrome oggi significa spesso alternare tre modalità: codice “a mano”, generazione assistita da un coding agent e una fase di verifica nel browser che resta comunque imprescindibile. Il problema è che molti agenti riescono ad aprire pagine e cliccare elementi, ma si fermano quando entrano in gioco le estensioni: installazione, gestione del popup, interazioni con la UI dell’estensione, verifica rapida dei cambiamenti. Chrome DevTools for agents colma proprio quel vuoto: aggiunge al set di strumenti dell’agente la possibilità di installare e pilotare un’estensione durante i test, oltre a renderne più pratico il debugging. Quando è davvero utile Ci sono alcuni scenari tipici in cui il supporto “estensioni-aware” fa la differenza: Ciclo di feedback più rapido : compili/packi l’estensione, la carichi in Chrome e verifichi subito il popup o una content script UI. Test end-to-end più realistici : invece di simulare una UI in una pagina fittizia, testi l’estensione nel suo contesto reale (action popup, permessi, storage, ecc.). Validazione automatizzata : l’agente può controllare che l’estensione si installi correttamente, che il popup si apra e che i componenti principali siano presenti e interagibili. In pratica: se il tuo agente sa “guidare” il browser ma non sa “gestire” le estensioni, la qualità del test rimane limitata. Setup: abilitare esplicitamente gli strumenti per le estensioni Un dettaglio importante: per ragioni di sicurezza e controllo (in particolare per l’uso dei token e del contesto in cui operano gli agenti), le funzionalità specifiche per estensioni non sono abilitate di default . Dopo aver installato Chrome DevTools for agents, serve quindi un passaggio esplicito nella configurazione MCP: individua il tuo file di configurazione MCP ; abilita la categoria dedicata alle estensioni aggiung

We build GPTree with several coding agents working the same repository at once: Claude Code, Codex, and Cursor, each in its own git worktree. The failure that finally made us build tooling for it was small and completely silent. One session was told to replace PaymentService with a Stripe-specific implementation. Another was told to add PayPal support to PaymentService . Different worktrees. Different files. Zero textual conflict. Git merged both branches cleanly, and the second change now depended on an extension point the first had deleted. Nothing in the toolchain had an opinion about it at any moment. Git compares diffs. It cannot compare plans. Worktrees isolate files, not plans Worktrees became the standard answer to parallel agents for a good reason: two sessions editing one checkout will overwrite each other's files and poison each other's context. Isolated checkouts fix that completely. But three failure modes survive file isolation, because they were never about files: Destructive versus additive. One agent removes or replaces a thing another agent is building on. The example above. Merges clean, breaks the design. Duplicate work. Two agents solve the same problem from different angles because nothing assigned ownership. You pay twice and then pay again to reconcile. Contract drift. One agent changes an API, a schema, or a config contract while another codes against the old shape. Compiles, runs, disagrees at runtime. A shared task list helps with the second one, if every agent reads it, every time. Nothing in that setup catches the first or third, because the collision is between intentions, and intentions live in prompts, not in any file a tool can watch. Declare the work before doing it Foremerge is the internal tool we built for this, open-sourced this week. It is a coordination protocol that sits above Git: agents declare what they are about to do, before they do it, in a form precise enough to check. A declaration is an intent with one or more semant

How I automated my content distribution with a DSH plugin I scaffolded myself Posting is easy. Posting everywhere, consistently, is the hard part. I wanted a single command that takes one markdown article and pushes it to Dev.to, GitHub (as a gist), and eventually Bluesky and Mastodon — without my ever touching those web editors again. So I built it as a plugin for DSH (DeepSeek Harness) , using a scaffolding tool that I published myself. Here's the story, the 3 pitfalls that cost me the most time, and how you can get the same thing running in about a minute. Why automate distribution at all? Writing in public is the cheapest compounding asset a developer has. But cross-posting manually has two failure modes: You skip platforms — the "I'll do it later" tab that stays open forever. You lose the content graph — each platform becomes a silo with a slightly different version. A plugin that accepts content + title + [platforms] and returns per-platform status + links removes both. One source, many destinations, audited every time. What I built A DSH content-automation plugin ( dsh-crosspost ) with: Platform adapters : Dev.to (real), GitHub gist (real), Bluesky + Mastodon (stubs, next milestone). BYOK credentials : your tokens live in your DSH profile config — never in code, no platform approval needed from the plugin author. Error classification : every adapter wraps HTTP in try/catch and returns auth / rate-limit / bad-request instead of a raw stack trace, so an agent can decide to retry or skip per platform. Parallel orchestration : one platform failing never blocks the others. The 3 pitfalls that cost me the most time 1. The stale latest dist-tag (the big one) npm install @deepseek-ai/dsh-tools gives you a stale 0.0.1-rc.1 — the real line lives under the next tag. Wasted an evening debugging failures that were purely "wrong version resolved." Lesson: check dist-tags before installing anything in a fast-moving young ecosystem ( npm view pkg dist-tags ). 2. Pure ESM + b

MCP Was a Mistake. Here Are 200,000 Tokens That Prove It. "mcp were a mistake. bash is better." — Peter Steinberger, OpenClaw founder I didn't want to believe it either. MCP was supposed to be the USB-C of AI — one protocol to connect everything. Anthropic, OpenAI, Google all backed it. 97 million monthly downloads. 17,000 servers. But then I measured what MCP actually does to your context window. The Setup I connected 10 popular MCP servers to a token counter. Here's what happened before I typed a single word: Server Tools Tokens Injected Filesystem 11 3,847 Brave Search 8 2,103 Sequential Thinking 3 890 Memory 9 2,567 Puppeteer 15 5,890 Postgres 19 8,231 Notion 24 13,780 GitHub 28 12,440 Slack 22 14,672 Google Drive 31 47,293 Total 170 111,713 111,713 tokens. Before your first message. That's not a typo. Connecting 10 MCP servers to Claude means over 100K tokens of JSON schemas get injected into your context window. You haven't asked a question yet. You haven't made a tool call. The schemas are just... sitting there. The Math That Made Me Angry At Claude 3.5 Sonnet pricing ($3/M input tokens): Every conversation starts with 111K tokens of overhead: $0.33 20 conversations per day: $6.67/day 22 working days per month: $147/month Annual cost of JSON schemas: $1,764 That's more than a Claude Pro subscription. You're paying $1,764/year to read JSON braces describing tools you might never use. But Wait — It Gets Worse The 111K is just the schema injection. When you actually call a tool, MCP wraps the result: { "content" : [ { "type" : "text" , "text" : "{ \" file \" : \" app.py \" , \" size \" : 1024}" } ] } The actual content is 38 characters. The wrapping is 47 characters. 55% of your result tokens are JSON overhead. With 20 tool calls per conversation: Schema injection: ~111K tokens Result wrapping: ~18K tokens Total overhead: ~130K tokens per conversation Your $0.54 conversation now has 130K tokens that serve zero purpose. What Garry Tan Was Right About When YC's CE

Claude Code Is Burning Your Token Budget. Here's the Receipt. I found $2,500/year of hidden token waste in my Claude Code setup. It was the MCP servers. The Discovery Last week I noticed my Claude Code conversations were dying at around message 15. Context window full. The model starts forgetting earlier instructions. Tool calls fail. The conversation degrades into hallucination. I assumed it was my fault — too many messages, too much context. So I started measuring. Here's what I found: Session start: Claude system prompt: ~8,000 tokens MCP schema injection: ~111,000 tokens User's first message: 50 tokens ────────────────────────────────────────── Total before any work: ~119,000 tokens Remaining context: ~81,000 tokens I was starting every conversation with 60% of my context already consumed. The culprit wasn't my prompts. It was the 10 MCP servers I had proudly configured in my claude_desktop_config.json . The Receipts I measured each server's schema injection using tiktoken: Server Why I Installed It Token Cost Times Used/Week GitHub PR reviews, issues 12,440 3 Slack Message reading 14,672 0 Google Drive Doc access 47,293 1 Notion Knowledge base 13,780 2 Postgres Query DB 8,231 4 Puppeteer Screenshots 5,890 0 Filesystem File access 3,847 15 Brave Search Web search 2,103 5 Memory Context persistence 2,567 0 Sequential Thinking Reasoning 890 2 Total 111,713 Look at the "Times Used/Week" column. Three servers were used zero times. Two more were used once or twice. But every single one of them was injecting 100% of its schema into every conversation. I was paying $0.33 per conversation — $2,500/year — to load schemas for tools I barely used. The Moment I Realized Everyone Has This Problem I posted my findings on Bluesky. Within hours: "I had the same issue. Removed 6 MCP servers and my conversations went from dying at message 15 to lasting 40+ messages." — @developer1 "GitHub MCP is 12K tokens but Claude Code already has gh CLI built in. Why did I install it?" — @dev

Garry Tan Was Right: "MCP Sucks Honestly." I Have the Token Receipts. "MCP sucks honestly. Context window eats too much, auth is a mess. I wrote a CLI wrapper in 30 minutes and it works better." When YC's CEO says this on X, people listen. But nobody had the data to back it up. Until now. What Garry Tan, Perplexity's CTO, and 97 Million Downloads Can't Hide Three things happened in the last 6 months that changed how I think about MCP: Peter Steinberger (OpenClaw founder) tweeted: "mcp were a mistake. bash is better." Eric Holmes wrote "MCP is dead. Long live the CLI" — it hit HN frontpage Denis Yarats (Perplexity CTO) publicly announced they're replacing MCP with REST API + CLI internally Garry Tan (YC CEO) replied: "MCP sucks honestly" The community split into two camps: "MCP is dead" — CLI is simpler, cheaper, faster "MCP is fine" — 97M downloads, 17K servers, it's the standard Both are wrong. The problem isn't MCP. The problem is what MCP does to your context window. The 47,000-Token Problem Nobody Measured I connected 10 MCP servers to a token counter. Here's what I found: MCP Server Tools Token Cost Equivalent Sequential Thinking 3 890 This blog post Brave Search 8 2,103 A short email Filesystem 11 3,847 A README Memory 9 2,567 A meeting note Puppeteer 15 5,890 A chapter of a book Postgres 19 8,231 A whitepaper GitHub 28 12,440 A court filing Notion 24 13,780 A legal contract Slack 22 14,672 A novella chapter Google Drive 31 47,293 Half of a novel Total 170 111,713 A short book One MCP server — Google Drive — injects 47,293 tokens into your context before you ask a single question. The entire works of Shakespeare is 900K tokens. Google Drive's schema is 5% of Shakespeare. For listing files. The Cost Breakdown (So You Can Get Angry Too) At Claude 3.5 Sonnet pricing ($3/M input tokens, $15/M output): Scenario Tokens Cost Annual Cost 1 server (minimal) 3,847 $0.01/conv $4.40/yr 3 servers (common) 14,528 $0.04/conv $19.40/yr 5 servers (typical) 33,061 $0.10/conv $4

I Benchmarked 10 MCP Servers — One of Them Burns 47K Tokens Just to Say Hello 10 popular MCP servers. 847 tools total. 312K tokens of JSON schemas. One server alone wastes more tokens than a full GPT-3 conversation. Here are the results. What I did I installed the 10 most popular MCP servers from the official registry. Connected each one to a token counter. Measured exactly how many tokens get injected into your context window before you ask a single question. The servers: # Server Tools Token Cost 1 Filesystem 11 3,847 2 GitHub 28 12,440 3 Postgres 19 8,231 4 Puppeteer 15 5,890 5 Brave Search 8 2,103 6 Memory 9 2,567 7 Sequential Thinking 3 890 8 Slack 22 14,672 9 Google Drive 31 47,293 10 Notion 24 13,780 Totals: 847 tools across 10 servers 111,713 tokens of JSON schemas 200,000+ tokens including server status messages, headers, and error schemas That's right — connecting 10 MCP servers to Claude means 200K tokens of overhead before your first message . The worst offender: Google Drive Google Drive's MCP server exposes 31 tools. Each tool has deeply nested schemas for file operations, permission management, sharing, and search. The full schema dump: { "name" : "drive.files.list" , "description" : "Lists files in the user's Google Drive with optional filtering" , "inputSchema" : { "type" : "object" , "properties" : { "q" : { "type" : "string" , "description" : "Query string for filtering files..." }, "corpora" : { "type" : "string" , "enum" : [ "user" , "domain" , "sharedDrive" , "allDrives" ]}, "includeItemsFromAllDrives" : { "type" : "boolean" }, "orderBy" : { "type" : "string" }, "pageSize" : { "type" : "integer" }, "pageToken" : { "type" : "string" }, "spaces" : { "type" : "array" , "items" : { "type" : "string" }}, "supportsAllDrives" : { "type" : "boolean" }, "fields" : { "type" : "string" } }, "required" : [] } } That's ONE tool. 31 of them. At ~1,525 tokens per tool average. 47,293 tokens. Just for Google Drive. For comparison, the entire works of Shakespea

There is a small cluster of posts going around right now about auditing your LLM invoice, and about how cost calculators get the numbers wrong. I went to check mine and hit a problem before I got to the arithmetic: my pipeline doesn't produce an invoice, and the plumbing I built two months ago is the reason why. This project has a script, git_commit.py , that turns a staged git diff into a Conventional Commit message. It shells out to the Claude CLI. There is no ANTHROPIC_API_KEY anywhere in the project, on purpose — an early version used urllib against the API directly and broke immediately for anyone running on an OAuth session instead of a raw key, so every AI call in the repo goes through a claude -p subprocess instead. That decision is still right. It also means there is no API key, so there is no per-key usage dashboard, so there is no line item to audit. For several months this script has been making a model call on essentially every commit, and I have never once known what any of them cost. The call site throws the numbers away Here is the actual invocation, trimmed: raw = subprocess . check_output ( [ " claude " , " -p " , " --safe-mode " , SYSTEM + " \n\n " + diff ], text = True , timeout = 20 , env = _claude_subprocess_env (), ) subprocess.check_output returns stdout. With the CLI's default output format, stdout is the commit message string and nothing else. Every number I would want — tokens in, tokens out, dollars — is computed on the other side of that call and then discarded, because I asked for a string and a string is what I got. This is the part I want to flag for anyone wiring up a headless model call the same way. It isn't that the metering is missing. It's that the default output format is lossy in exactly the dimension you'd later want to audit, and you won't discover that by reading your own code, because your own code looks fine. It asks for text, it gets text. The fix is one flag: raw = subprocess . check_output ( [ " claude " , " -p " , " -

This week shipped one of the more consequential infrastructure changes in a while: DynamoDB absorbed vector search, collapsing a common two-database architecture into one. Meanwhile, a CMU study put hard numbers on something senior engineers have suspected about AI coding tools, and a 3B parameter model posted reasoning scores that have no business coming from a model that size. DynamoDB adds native vector search without a separate database AWS added a SearchVectors API to DynamoDB, letting you store embeddings alongside your application data and query them directly—no Pinecone, no Weaviate, no synchronization layer between your transactional store and your vector index. This matters because the dual-database pattern is genuinely painful at scale. You write to DynamoDB, you write to your vector DB, you manage consistency between them, you pay for two systems, and you debug failures in both. For RAG pipelines and semantic search on data that already lives in DynamoDB, that overhead exists purely because vector search wasn't available where your data was. Now it is. Setup requires picking an embedding model (Bedrock, Cohere, or OpenAI), configuring a vector index with dimensions and distance function, and rewriting retrieval queries to SearchVectors . Vector operations are billed separately per GB across writes, reads, and storage—so run the math before assuming this is cheaper than your current setup. Verdict: Ship if you're already on DynamoDB and maintaining a separate vector DB. The architectural simplification is real. Start with a proof-of-concept on a non-critical workload to validate cost and latency before migrating production RAG infrastructure. AI coding speed spike vanishes in three months Carnegie Mellon tracked 806 repositories after Cursor adoption and found that the velocity boost disappears by month three. What doesn't disappear: a 30% increase in warnings and 41% higher code complexity that persists indefinitely and cuts future velocity by 50–64%. Th