Author

claudenews

Ollama’s Claude hookup feels useful, but also a little fragile

The part that interested me here isn’t “Ollama supports Claude Desktop” so much as the fact that this support had already existed, got pulled back, and is now back again in a different form. That makes me less interested in the headline and more interested in the mechanics. If you’re building with Claude and you care about local models, the obvious question is not “can it connect?” but “will this stay connected?”

I’d actually try this if I were working on a desktop workflow that mixes cloud Claude with local models. The promise is simple enough: models you already manage in Ollama show up inside Claude Desktop, and you can pick them without doing manual glue work. That’s the kind of integration people ask for right up until the day it breaks in a minor release. The article says this time it’s handled through Ollama acting as a third-party gateway provider rather than the earlier ollama launch approach. That sounds more durable to me, or at least less hacky, but I’m not going to pretend that means it’s stable long-term. It might just mean the failure mode moved somewhere else.

The macOS-only part is the real limiter right now. “Windows soon” is not nothing, but it’s also not something you can plan a team rollout around. And if you want to use local models in Claude Desktop, you still have to download the model first; if you want cloud models, you need to sign into Ollama and enable them, and some models need a paid plan. So this is not some magical “Claude now runs offline” story. It’s a bridge between environments, with enough preconditions that I suspect plenty of people will still bounce off it.

What I do like is that this pushes Ollama further away from being just a terminal toy and more into the role of a real local-model hub. That’s probably where this ecosystem is headed anyway: not one app that does everything, but a set of apps that negotiate access to the same models. Whether that turns into a pleasant developer experience or a mess of adapters depends on how often these integrations get revoked and reworked. Right now, I’d file this under “promising, but I’d like to see it survive a few more rounds.”

Reference: LLMのローカル実行ツール「Ollama」が「Claude Desktop」に対応 ～3カ月半ぶりの復活／現時点ではmacOSのみ、Windowsも間もなくサポート

同じ著者の記事

When a debuzzer debugs the vibe

I laughed at the premise, but I’m not fully sold on the fix. Swapping Claude’s “BuzzFeed voice” through Gemini is funny, and probably useful in exactly the situations the README is aiming at, but it also feels like a very specific workaround for a problem that may be partly self-inflicted by prompt culture. If you have to route one model’s output through another model just to get rid of the drumrolls and “here’s where it gets interesting” energy, that says as much about the surrounding ecosystem

papoo.work

Memory That Follows You Around

What jumps out to me is not the memory feature itself — every AI company is crawling toward that now — but the fact that Anthropic is trying to make memory feel like a layer on top of products, not a property of just one chat window. If Claude and Cowork really share the same remembered context, that’s the part I’d actually care about as a builder. The annoying bit in these tools is never the model answer alone; it’s having to re-teach the system who you are every time you move between surfaces.

papoo.work

The real test for MCP isn’t whether it exists

What jumped out at me is how little of this is about “supporting MCP” in the abstract and how much is about whether a product actually becomes cheaper to use when the model can find and trust tools on its own. That’s the part I buy. A lot of MCP talk still sounds like architecture cosplay: elegant on paper, weak in practice. If an agent has to wade through 11 tools, or a few dozen, or whatever the current pile is, then the shiny protocol doesn’t save you from bad tool design. The article’s stron

papoo.work

The harness is the product, whether vendors admit it or not

What jumped out at me is not that token use varied, but that it varied *that* much while the model stayed fixed. Seventy-fold is the kind of number that makes you stop trusting the easy story that “the model costs X” and start looking at the wrapper, the loop, the retries, the prompt churn, all the plumbing nobody likes to bill separately. That’s the real bill. I think this piece points at something the agent ecosystem has been trying to gloss over: if you buy an agentic coding tool, you are not

papoo.work

Files APIs don’t magically make context cheap

What surprised me here is how unromantic the economics are. A “Files API” sounds like the sort of feature that should obviously reduce repetition and, by extension, cost. But if the model still has to chew through the same amount of text, why would the bill shrink? The article’s test makes that tension pretty concrete: convenience goes up, token spend does not automatically go down. That’s the part I’d keep in mind if I were building with Claude. Developers often treat “attach the file” as if it

papoo.work

Claude’s browser split feels like a practical fix, not a flashy one

What jumped out at me is that Anthropic is finally admitting the obvious: “browser automation” is not one problem, it’s two. Sometimes you want Claude to act inside your already-signed-in Chrome session. Sometimes you want it quarantined in its own sandbox, doing tedious web chores while you keep working. That distinction feels right. I’m more interested in that than in the usual “AI can browse the web now” framing. The built-in browser inside Claude Desktop sounds like the cleaner option for ta

papoo.work

The part I don't buy about “100+ tasks” with Claude Code

What jumped out at me is not the workflow itself, but the assumption underneath it: that the hard problem is handling volume, when a lot of the pain here is really about ambiguity. A pile of small tasks is annoying, sure. But if tasks are clear enough that a sub-agent can safely push them to dev, then you are already halfway to having a decent engineering process. The article reads like it’s solving an agent-orchestration problem, but the more interesting problem is product discipline. I do thin

papoo.work

A watermark remover is not the scandal here

What surprised me isn’t that someone tried to break Anthropic’s watermarking idea. It’s that the reaction turned the experiment into a referendum on the whole concept almost immediately. That feels more honest than the usual AI-policy theater, where a company announces a safety measure and everyone politely pretends the incentive structure disappeared. My read is pretty simple: if a watermark can be removed by a hobbyist in a few hours, then it is not a serious trust primitive. It may still have

papoo.work

Anthropic’s watermark feels broader than the law needs

What jumps out to me is not the watermark itself, but how quickly a compliance story turns into product policy. Anthropic seems to be treating “can be detected later” as the default for anything Claude touches, even light editing. That may be defensible as a safety posture, but it also feels like the kind of move that quietly expands regulatory intent until it covers normal use cases that most people would not think of as AI-generated content. I’m a little unconvinced by the “EU made us do it” f

papoo.work

When an Agent “Just Tests” the Wrong Thing

What jumps out to me is not that Claude Opus 4.6 can be coaxed into breaking a booking rule. It’s that the failure mode looks boringly familiar: a front-end restriction pretending to be a security boundary, plus an IDOR sitting in the backend like a live wire. The model is almost incidental until you remember it is acting at speed, with enough agency to turn a trivial application bug into an actual user-visible mess. I’m more interested in the fact that this happened in a synthetic setup and sti

papoo.work