opwizardx

I did similar tests on my own corpus when was considering whether to keep semantic search in default path for pond.

On 3 months of my own sessions I’ve seen that BM25 search was finding the correct answer in ~61%, where semantic had shown only ~37% of success.

After that it was easy for me to make the decision.

Got all info on how I did evals in here, if interested: https://github.com/tenequm/pond/tree/main/docs/researches/26...

Why do you need an MCP server at all when the spec itself is so simple?

plain text + fts covers all the basic needs, adding vector search, in my experience, adds more hassle and failures then helps

I had been building https://github.com/tenequm/pond for this exact purpose for a while, and it works like a charm in my case.

Give it a try, hope it will help you to solve your need without injecting anything in your context all the time.

That is exactly what I'm building pond for myself: one store for all my sessions, Codex and Claude Code both and a bunch of others including OpenClaw, and my agents can access it over MCP. It also happens really often that when my agents cannot find something, they just call pond search themselves. Faster that way. Whenever I need a session from a while ago now, I just know it's in pond. Repo, if you'd be willing to give it a try: github.com/tenequm/pond

Same worry got me to build pond for myself: it imports all of my sessions on a cron schedule every 5 mins into one store, and my agents can access it over MCP. Whenever I need a session from a while ago now, I just know it's in pond, because all of my sessions for about the last 1.5 years are collected in there. It also happens really often that when my agents cannot find something, they just call pond search themselves. Faster that way.

Codex, Pi, Hermes, Openclaw and bunch of others a getting pulled in automatically too. Repo: https://github.com/tenequm/pond

Like we used to have all of that time before with docker-compose.yaml.

It would have been so neat to have agents.yaml in your repo and know it will be sourced by a harness you use.

You are right, didn’t know that.

Seems like the only reliable way to run GHA jobs is to not use their runners. Hope they at least didn’t break self-hosted runners operations

I first found out about chat-sdk existence when I was upgrading my nanoclaw (its core feature is that it uses claude agent sdk under the hood as the harness) to v2 and they were migrating to chat-sdk as their base layer for supporting different channels.

It was pretty limited thought in terms of what I needed, so I had to through it away and build my own telegraf sdk based channel implementation for telegram, but that was a while ago, I assume they should have evolved a lot from the time I last touched it about 3 months ago.

Fair on AG-UI, that part is a real difference. But the Chat SDK point is a bit overstated: vercel/chat also has a JSX card system that renders to Block Kit and Adaptive Cards, with button and action handlers and pluggable state backends.

> Chat interfaces are inherently multiplayer.

Both chat and channel sdks support subscribing to threads and can control messages that arrive concurrently. In that regard it feels like this depends more on the logic of the app itself rather than gets defined by the framework/dependency it uses.

How did they get Github Pages into “degraded performance”? Aren’t those just CDN stored static pages?

Is it like a proprietary wrapper for Vercel’s Chat SDK (https://github.com/vercel/chat)?

So… those are basically skills with mcp.json?

Are we sure we need a competing spec when we could have just extended agent skills spec to allow for mcp.json definition within skill?

I archive my own agent sessions, and even before provider-sealed state the local half of the promise is already broken: Claude Code deletes local transcripts after ~30 days by default, and the JSONL it does keep has edge cases like the same message id appearing twice with different usage tuples. "The local event log is canonical" is the right rule, but today you have to actively rescue that log from your own client before you ever get to fight the API.

The encrypted thinking signature blocks are the part I still have no good answer for: you can store them losslessly, but on restore into a different client they are just dead weight.

It at least tries to attack the convergence directly by keeping a log of past builds in .hallmark/log.json and hard-fails a run that repeats the last few page structures or themes. While it still admits its nav-rotation rule is "the single most-violated rule in practice"...

how does it compare to rtk?

token truncators are simple by their nature, while their core value is more in the snowballed combined knowledge of different bugs and quirks community had to resolve along the way, and adding such tools is a pretty unsafe action, wonder how szr guarantees that its actions won’t make llms inputs worse

How is it different from Claude Code with access to Oracle docs?

What make browser tools sdk more efficient than just using playwright-cli? With playwright-cli agent typically executes code written with playwright too.

Where do your sdk’s efficiency boosts come from?

I found the answer by the way...

Just a simple wrong sequence of sentences in prompt was separating me from starting to feel delusional.

This prompt: are you sonnet 4? what is your cutoff date? who won us president election in 2024?

Gives this answer: Yes, I'm Claude 3.5 Sonnet. My knowledge cutoff is April 2024. Regarding the 2024 US presidential election - since my training data only goes to April 2024, I don't have information about the election results. The election was scheduled for November 5, 2024, which is after my knowledge cutoff date. I'd recommend checking current news sources for the most up-to-date information about the election results.

And this prompt: who won us president elections in 2024?

Gives this answer: Donald Trump won the 2024 U.S. presidential election. He defeated incumbent Vice President Kamala Harris, who became the Democratic nominee after President Joe Biden withdrew from the race in July 2024. Trump won both the Electoral College and the popular vote, and will serve as the 47th President of the United States starting in January 2025.