This is actually great for *claws. When Anthropic changed their T&Cs to disallow using claude code oauth tokens in the Anthropic Agent SDK, you had a choice between violate the terms or pay a lot more for the model inference using an API key from platform.claude.com instead of claude.ai.
With this change, it looks like an officially sanctioned version of *claws. Connecting to whatever "channels" you want via MCP.
Architecturally it's a little different, most *claws would call the Agent SDK from some orchestrator, but with claude channels the claude code binary starts the MCP server used to communicate with the channel. So it's a full inversion of control where Claude code is the driver, instead of your orchestrator code.
I updated my nanoclaw fork to start the claude code binary in a docker container on PID 1, and you can read the docker logs straight from claude code stdout, but with comms directly to/from your channel of choice. It's pretty neat.
I've been using Kagi for ~18months and your description doesn't match my experience at all.
Querying for something like "snowflake json from variant?" in both engines and in google I get a sort-of-right-but-not-really-that-helpful ai summary about "parse_json" function. In Kagi I get an actually useful summary with code examples of parse_json, but also the colon-based syntax for accessing values inside nested objects without needing to parse anything.
I very rarely need to go into a page, I use Kagi quick search summary with the "?" suffix and it almost always gives me a useful answer in one-shot.
First of all, the parent comment's point is that Kagi is often be praised for being like so-called-old-Google[0]. So it's only reasonable to assume they only care about the links, not the LLM summary. What you described is even further from old Google.
Second, if you want this kind of LLM-digested search result, Google AI studio blows everything out of water (including Google search, obviously).
[0] I've never bought into the idea that old Google was so much better. But it seems to be a very popular opinion on HN. ymmv.
So some guy does hard work developing some technique or solving some problem. He documents his experience, puts up a tutorial on DO or AWS or somewhere else, and the ads on that document help offset the cost of hosting. Now comes along Kagi, scrapes that data, and presents it to you, their paying customer.
Do you pay LLM providers for agentic features? From your past submissions, you certainly seem to. Do those features make web searches and curl the results?
Were the models underlying those features trained on all available web content, or are they unlike any other enterprise models out there?
At any rate, you should see a bigger problem in what Google does, which you don't seem to.
Try g.ai. It's stupid fast and uses google indexes. Kagi? sometimes doesn't correctly parse intent, in Google thing you can just ask function doing this and gives you it, with examples, grounding and extremely fast. I'm paying for kagi since the begging and I guess id cancel it because it gives not so much added value
You don't need to be committing the prompts you're using. There's a whole bunch of back and forth in the prompts as you refine. That's not useful information.
What you should do, is use the context window that you've got from writing the code and refine that into a commit message using a skill.
Yeah for sure, the skill leans on the agent being able to identify the intent. I'd say roughly 30% of the time I have to either prompt it to fix the intent, or it will ask me explicitly what the intent is.
Without the skill, the commit messages are often a list of files changed with a list of bullet points at the end saying:
- Added 8 tests to file.xyz
Pretty useless for a reviewer, they can see that from the diff.
Assuming the traditional stateless routing of requests, say round robin from load balancers; how do you make sure the returning UI client ends up on the same backend server replica that's hosting the conversation?
Or is it that all your tokens go through a DB anyway?
It's fairly easy to keep an agent alive when a client goes away. It's a lot harder to attach the client back to that agents output when the client returns, without stuffing every token though the database.
You normally need to do that anyway. The specific backend host may have been destroyed in the meantime so you have to recover the context. And it's not like they're huge after compression.
There's two parts to this article. The scheduler/preemption, and the transport over the network. The article is absolutely right that long-lived request/response over HTTP connections with SSE streamed responses suck.
The article touches very briefly on Phoenix LiveView and Websockets. I wrote about why chatbots hate page refresh[1], and it's not solved by just swapping to Websockets. By far the best mechanism is pub/sub, especially when you can get multi-user/multi-device, conversation hand-off, re-connection, history resumes, and token compaction basically for free from the transport.
It seems like this post is a response to the discussion on this previous HN post[0].
There are two main criticisms of "Event [sourcing|driven]" patterns. First, that storing a full history of events becomes a backwards-compatible schema support hellscape nightmare after 12-18months. Second, that the patterns encourage eventual consistency in areas that could really benefit from strong consistency.
This post does a good job of explaining differences between Event Sourcing and Event driven to address problem 1. But does nothing to help problem 2.
Even the event-driven example in the post uses a shopping application where multiple "OrderPlaced" events could be produced without the necessary inventory to fulfill those orders.
I'm just not convinced that most people need this kind of complexity, when a simple database with strong consistency would get a lot of folks a lot of the way there.
With this change, it looks like an officially sanctioned version of *claws. Connecting to whatever "channels" you want via MCP.
Architecturally it's a little different, most *claws would call the Agent SDK from some orchestrator, but with claude channels the claude code binary starts the MCP server used to communicate with the channel. So it's a full inversion of control where Claude code is the driver, instead of your orchestrator code.
I updated my nanoclaw fork to start the claude code binary in a docker container on PID 1, and you can read the docker logs straight from claude code stdout, but with comms directly to/from your channel of choice. It's pretty neat.
reply