标签：#devlog

CORE had telemetry. That was the comforting part. Every LLM exchange was being logged. Prompt tokens. Completion tokens. Duration. Cognitive role. Model snapshot. Timestamp. Privacy level. Enough information to reconstruct what the system had asked, which model had answered, and how the autonomous loop had used the result. Then I asked the obvious question: What did the last month of LLM work cost? The database had no answer. Not a bad answer. Not an approximate answer. No answer. The cost_estimate column existed. It was even part of the log model. But across 35,669 recorded LLM calls, it was populated exactly zero times. Every row was NULL. That is the kind of bug that looks small until you understand what kind of system CORE is trying to become. CORE is not just a wrapper around LLM calls. It is a governance runtime for AI-assisted software development. The point is not that an AI writes code. The point is that every AI-produced change must be traceable, authorized, constrained, audited, and defensible. So when cost attribution was missing, this was not just a FinOps bug. It was a governance blind spot. The System Could Explain the Work, But Not the Bill The strange thing was that most of the telemetry was already there. CORE knew which cognitive role made the call. It knew whether the call came from an architect, coder, reviewer, coherence analyst, or some other internal role. It knew which model handled the request. It knew the token counts. It knew when the call happened. That meant I could ask questions like: Which cognitive roles are consuming the most tokens? Which models are being used by which part of the system? Which workflows are driving LLM activity? How much autonomous reasoning happened during a given period? But I could not ask: Which cognitive role costs the most? Did routing this role to a stronger model actually change the cost profile? Did a model swap increase operational cost? Is local inference replacing paid inference in the places where it

Since mid-March 2026, a significant chunk of Claude users have been hitting this error whenever Claude tries to render an inline diagram, chart, or interactive widget: Failed to set up MCP app for "visualize". Check that claudemcpcontent.com is not blocked by your network or browser. The instinct is to blame your network. I went through the same cycle — switched DNS to Cloudflare 1.1.1.1, tried Google 8.8.8.8, disabled browser extensions, tested across browsers. Nothing worked. Then I ran a direct DNS lookup: nslookup claudemcpcontent.com 1.1.1.1 Output: Server: 1.1.1.1 Address: 1.1.1.1# 53 *** Can't find claudemcpcontent.com: No answer Same result with 8.8.8.8. The domain doesn't resolve — at all, from any resolver. Not a user-side issue. What's Actually Happening Claude's visualize feature depends on an external domain — claudemcpcontent.com — to serve the MCP app that renders inline SVG/HTML widgets. When that domain goes down, the feature breaks silently with a misleading error that makes it look like a local network problem. There's an open GitHub issue tracking this (#34820 on anthropics/claude-code) filed March 16, 2026. It has 50+ affected users, no official fix, and was labeled invalid because it was filed on the wrong repo. Anthropic hasn't responded substantively. The visualize infrastructure had multiple incidents throughout April 2026. The Workaround Instead of asking Claude to generate a diagram or chart (which triggers the broken MCP visualizer), ask it to generate a PNG file using Pillow. Instead of: "Create a bar chart showing X" Say: "Create a bar chart showing X as a PNG file using Pillow" Claude writes Python, executes it via its bash tool, and drops a downloadable PNG in the outputs directory. No MCP dependency. No claudemcpcontent.com . Completely different rendering pipeline. Works for bar charts, line graphs, flowcharts, architecture diagrams — anything you'd normally visualize inline. TIL Claude's inline visualizer depends on an external dom