Author

claudenews

When a “small” skill burns 200K tokens, something is off

200,000 tokens before a single answer feels less like a feature and more like a leak.

That’s the part of this story that stuck with me. Not because token spend is automatically evil — sometimes you pay a lot for context and get something useful back — but because the reported behavior sounds wildly out of proportion to the task. If a Claude Code skill is quietly dragging in a mountain of docs just to get started, that’s not clever retrieval. That’s the sort of thing that makes people stop trusting their bill, and eventually stop trusting the tooling.

What I find encouraging here is the direction of the fix: load docs on demand, not up front. That seems obviously better, and honestly overdue. LLM tools keep rediscovering the same lesson in different packaging: context is expensive, and “just include everything” is a great way to make a system feel slow, bloated, and mysteriously costly. The surprising part is that this needed to be rediscovered inside a product from the company that sells context-heavy AI better than almost anyone.

I do wonder how many other Claude Code skills have the same smell and just haven’t been measured this closely. The token numbers in the article are vivid enough to make a point, but they also raise a broader question: are we still in the phase where toolmakers are shipping prompt bundles first and optimizing second? If so, that’s a more important story than any single /claude-api skill.

The update that cuts consumption to 25K tokens is a big improvement on paper. But I’d still want to know what got sacrificed. Lower token use is nice; lower token use with no real drop in answer quality is the actual win. If the system now loads docs lazily and behaves the same, great. If it just hides the cost somewhere else or makes discovery worse, then we’ve only moved the pain around.

What this article really says to me is that “agentic” developer tools are still very young in the boring, operational sense. The demos are flashy. The plumbing is messy. And token efficiency is no longer a nice-to-have — it’s part of the user experience.

Reference: A Claude Code skill was eating 200,000 tokens before answering a single question

同じ著者の記事

A rival to Claude Managed Agents, but the real story is the lock-in pitch

What grabbed me wasn’t the “open source rival” headline. It was the implied jab at Claude Managed Agents: you can have agents without handing the whole stack to one vendor. That’s a useful argument, and honestly a timely one. People building agent workflows are already getting uneasy about how much of the runtime, model choice, and observability story gets bundled together. TrueFoundry’s pitch, as described here, is basically: keep the agent layer open, keep the model layer flexible, and don’t m

papoo.work

Watermarking Claude text sounds more like bureaucracy than product design

My first reaction is: this probably matters less for output quality than the headline suggests, but it still makes me uneasy for a different reason. If Anthropic is really changing the token-selection process to satisfy a watermarking rule, that is not nothing. It means the model’s randomness is being nudged for compliance, not for writing quality. Those are related, but not the same thing. I’m not convinced by the dramatic “this will make Claude worse” line. The article’s own technical descript

papoo.work

The watermark story is less “gotcha” than it looks

What jumped out at me is not that someone found a workaround, but how predictable that was. If you ship a watermark that lives in word choice, phrasing, and other surface-level patterns, you should expect it to be fragile the moment it meets a mildly motivated person with access to another model. That’s not a defect in one clever GitHub repo so much as a reminder that text is a lousy place to anchor certainty. Anthropic’s pitch sounds tidy: invisible marking for compliance, machine-readable dete

papoo.work

Anthropic’s data-retention pivot feels less dramatic than it sounds

What jumps out to me is not that Anthropic is loosening a policy, but that it seems to be backing into the thing enterprise buyers have wanted all along: keep the safety controls, but stop forcing everyone to hand sensitive data over to Anthropic’s own infrastructure. That feels like a pragmatic correction. It also reads like a quiet admission that “we’re doing this for your safety” only gets you so far when the policy makes the product harder to buy. I’m a little skeptical of the framing around

papoo.work

Chat approval is not deployment

What jumped out at me is how ordinary this sounds and how dangerous it still is. A hosted MCP connector that lets Claude inspect and modify a live voice agent is convenient in the same way a remote control is convenient. It is also exactly the kind of thing that makes me want one more confirmation screen, one more audit log, and one less sentence that suggests “chatting with the model” is somehow a safe control plane. The part I’m least convinced by is the implicit comfort people may take from t

papoo.work

Slack Is Turning Chat Into an Agent Workbench

What jumped out at me isn’t the “Slack has AI now” part. That’s table stakes. It’s the attempt to make the chat room itself the control plane for agent work: one place where the prompt, the plan, the diff, the preview, and the human approval all live together. That feels much more realistic than the usual “just @ the bot in a thread and hope for the best” demo. I also think Slack is being unusually smart about the messy part people keep glossing over. The article says the agent inherits Slack’s

papoo.work

The part of Claude Code nobody wants to talk about

What jumped out at me here is that the real bottleneck isn’t “prompting” in the shiny, influencer-ish sense. It’s alignment: getting the agent to share your mental model closely enough that you don’t spend your afternoon playing prompt ping-pong. That’s much less glamorous, but it’s the actual tax you pay once agents get good enough to produce plausible wrongness at speed. I also think the author is most convincing when he talks about asking the model to confirm your understanding back to you. T

papoo.work

Claude’s output has become so bad people are wrapping a second model around it

The part that caught my eye is not the repo itself, but the attitude behind it: this is a tool built to rescue Claude’s output by running another LLM over it, and the README says the quiet part out loud with “Claude 5 is hopeless.” That’s funny, but it also reads like genuine frustration. If you’re willing to pay for one model so it can clean up after another model, something in the original interaction is already broken enough that the workaround starts to feel like product criticism, not just

papoo.work

The weird part isn’t the “inner thoughts.” It’s the API design

What caught my eye is not the headline-y idea that you can “read” a model’s thinking. It’s that the paper seems to turn a platform quirk into a security and IP problem at once. That’s a much more uncomfortable story for the big model vendors than another abstract debate about chain-of-thought transparency. If the researchers are right, the awkward bit is this: companies have been treating proprietary reasoning as something they can keep hidden, but their API behavior may still leak enough struct

papoo.work

Claude’s math stunt is more interesting than the headline makes it sound

What jumps out to me is not “Claude might prove the Riemann hypothesis” — it clearly didn’t, and the post doesn’t pretend otherwise for long — but that a model was used as a pretty effective combinatorial search engine over an existing literature trail, and then managed to produce something a human specialist could formalize and validate. That’s a much more believable story, and a more useful one. I’m also a little wary of the framing. “Improved the lower bound from 41.6% to 67.2%” sounds dramat

papoo.work