Every time agent memory comes up here, the conversation goes straight to MemGPT, vector databases, embedding pipelines. I get the appeal, you want to read the source, run it locally, own the data. But here is what actually happens when you self-host your agent's memory: you spend weekends maintaining retrieval pipelines instead of shipping agent logic.

The real problem most people have is not "I need to build a memory layer." It is "I need my agents and AI tools to remember the same context across sessions without me re-explaining everything." That is a different problem than "let me set up a vector DB."

A few things I have found matter more than the infrastructure itself:

Provenance: knowing which tool generated a thought matters more than raw storage. When retrieval mixes context from Cursor, Claude, and a custom agent without labeling where each piece came from, you get confident hallucinations grounded in nothing.

Rules that stick: personal style directives ("no tables," "short answers") should apply automatically on every new chat, not be pasted in manually each time.

Skills over improvisation: saving a reusable procedure once beats hoping the agent reconstructs the same steps next session.

Open-source memory tools give you transparency and control. A hosted layer gives you time back. The tradeoff is honest: how much infrastructure work are you willing to own before it eats your shipping time?

How about your chatgpt work?

I have a ChatGPT Pro subscription and a Claude Max subscription, and use both extensively for work. To claim that any model offered by OpenAI is even close in capability or problem solving ability to Fable is a joke to me.

To me, the most comparable Claude model to 5.6 Sol, OpenAI's flagship, is Opus 5. They have roughly equivalent price (ignoring the temporary promotions on Sol pricing), and in my experience, their output quality is about the same as well; I end up having to put in about the same amount of effort correcting them or giving feedback to achieve a product of comparable quality.

The main difference is in the kind of feedback I have to give; with Sol, I typically end up having to add details to its results, such as instructing it to address missing edge cases, or take a more thorough approach when it took a simpler shortcut to solve my problem instead. With Opus, it usually finds most edge cases for me without having to say anything; but it also goes beyond and keeps finding more and more things, of decreasing and often spurious relevance to my actual problem. My effort usually comes in the form of telling it to ignore those extraneous edge cases and focus on the core of the problem.

But when compared to Fable, neither can hold a candle. Among every task I've ever given any agent, Fable always takes the least amount of time, the fewest tokens, and needs by far the least number of warnings in the prompt or corrections to the output, compared to any other Anthropic or OpenAI model.

To me, to say GPT 5.6 Sol is anywhere close to Fable in any capacity, and not just a competitor to Opus with different tuning, is completely unfathomable to me. You pay twice the price for it and you get your money's worth. Sure it's expensive, and you can run through your weekly limits in hours, but you can't argue that it just works. I can't say the same about Opus or Sol.

I'm currently evaluating GitHub Copilot vs. Claude Code for our team. We could use either, but for us there's a slight difference in cost per token (Copilot with Anthropic models vs. Claude Code directly).

If we use the exact same model on the same repository with identical instructions, has anyone noticed a real difference in token efficiency between the two harnesses? I'm wondering how much things like prompt caching, context assembly, or system prompting overhead change the actual token burn in practice.

Would appreciate any insights or real-world numbers!

Hello!

I was using today sol on medium, and my 5h limit was gone in 40-50 minutes. Anyone observed something like this in the last 2 days? They said that they are fixing some bugs because of this issue (obver token comsumption). Is worse than before. I was having sol on medium for almost two hours, sometimes more than that.

Same thing for others??

I keep seeing this question in the community. Here's what I actually tried, why it broke, and what I ended up shipping.

The problem

When you're running multiple agents across a session (one that writes, one that reviews, one that deploys) you need them to share state. Not just conversation history. Actual verified state: what changed, what's blocked, what evidence exists that a task is done.

What I tried first (and why it failed)

Attempt 1: I maintained the handoff notes myself

After every session, I updated a Markdown file. This worked until I finished tired and skipped the update. The next agent read stale context as if it were current. Worse: even when the file was accurate, I was still the router, a human bottleneck between every agent transition.

Attempt 2: I let agents maintain the notes

The agent finished its work, updated the handoff, and the next continued from there. Then I noticed the real problem: an agent could write "tests pass" just as easily as it could actually run the tests.

Agent A would write: "Refactored auth. Tests pass."

Agent B had no idea which tests ran, against which version, or whether the slow integration suite was skipped. It didn't inherit verified work. It inherited a story about the work.

What I built

Three principles became the foundation:

State in fields, not paragraphs. What changed, what's blocked, what's unresolved as explicit fields, not embedded in a summary. An agent can't make unresolved work disappear by writing a nicer paragraph.

The agent that does the work can't approve it. A separate reviewer starts from the original goal and inspects the result directly, not from the implementing agent's explanation of why it's probably done.

Machine-checkable claims need evidence attached to a specific version. "Tests pass" is a claim. A test result attached to the exact commit hash is evidence. If the code changes after the evidence was produced, the evidence doesn't automatically transfer.

This became an open-source project (link in comments).

Results over 30 days of dogfooding

4,172 PRs merged across 16 repositories, one maintainer

Coordination overhead stayed roughly flat from 3 agents to 10; adding agents stopped adding to my mental load linearly

Stale-context bugs dropped to near zero because agents can't declare victory without attached evidence

The number I actually care about: my day looks the same with 3 agents as with 10. That wasn't true before.

What didn't work

The reviewer agent still occasionally fails to distinguish "the goal changed mid-task" from "the implementation is wrong." We handle this with an explicit goal-hash that both agents reference, but it adds friction. Still working on the right UX for that.

Has anyone else hit the "agent self-reports done but the work isn't clean" problem? Curious what enforcement patterns people are using, if any.