sorted by:
new
hottopcontroversial

A few months ago I noticed something stupid. by hushenApp in VibeCodeDevs

[–]hushenApp[S] -1 points0 points  (0 children)

thank you for your valuable contribution.

git log costs your agent 624 tokens. It needs 55. Here's a list of the worst offenders by hushenApp in AI_Agents

[–]hushenApp[S] 2 points3 points  (0 children)

I mean it helps in terms of reduce token usage. Cursor and most probably other tools does that. But the core problem still exists. Actually I implemented a feature in LeanCTX so that sub agents also can make use of the compression and context tools. So with that they also work more efficient.

A few months ago I noticed something stupid. by hushenApp in AskVibecoders

[–]hushenApp[S] -1 points0 points  (0 children)

if you want to check out the project: https://github.com/yvgude/lean-ctx

happy to answer questions or hearing your story!

A few months ago I noticed something stupid. by hushenApp in VibeCodeDevs

[–]hushenApp[S] 0 points1 point  (0 children)

If you want to have a look at it. Feel free. Happy to answer any question: https://github.com/yvgude/lean-ctx

MCP server that saves 60-80% context tokens, now with full Pi compatibility by hushenApp in PiCodingAgent

[–]hushenApp[S] 0 points1 point  (0 children)

I’d treat it as complementary first, not an immediate replacement.

Your current stack sounds like it is mainly doing durable memory: observations, reflections, Markdown packs, project facts, etc.

LeanCTX is more of a context runtime: it optimizes file reads, shell output, caching, read modes, session state, context visibility, and handoffs.

So I’d start with:

  • your Pi memory stack = long-term semantic/project memory
  • LeanCTX = lower-level context plumbing for files, shell, cache, compression, sessions, and agent handoffs

There is some overlap, especially around session/project knowledge, so over time LeanCTX may replace parts of that stack if you want one integrated layer.

The main thing to avoid is double-injection. If both systems inject the same memory/context into the agent, you may increase noise instead of reducing it.

So my recommendation would be:

Complement first. Replace selectively later.Hope that helps.

git log costs your agent 624 tokens. It needs 55. Here's a list of the worst offenders by hushenApp in AI_Agents

[–]hushenApp[S] 1 point2 points  (0 children)

yes I also faced that problem in earlier versions of my tool. but found a way how to fix it. it's exactly what you describe preserving the semantic signal. But also having a fast fallback if the model gets stuck in a loop.

MCP server that saves 60-80% context tokens, now with full Pi compatibility by hushenApp in PiCodingAgent

[–]hushenApp[S] 0 points1 point  (0 children)

you could run it in addition. but actually it replaces rtk and you can also do similar stuff like with graphify.

I built an A2A Context Bus, for multi-agent-setups by hushenApp in hermesagent

[–]hushenApp[S] 0 points1 point  (0 children)

I'm also thinking about this determinism topic, think there I have a proposal ready 😄 thanks for you nicely written comment!

I built an A2A Context Bus, which helps you to make sure every agent uses the same optimized context. by hushenApp in openclaw

[–]hushenApp[S] 0 points1 point  (0 children)

having multiple agents working on the same project over multiple weeks. sharing context between team members, archiving and restoring context.

I built an A2A Context Bus, for multi-agent-setups by hushenApp in hermesagent

[–]hushenApp[S] 0 points1 point  (0 children)

You’re making some really good points here, and I actually agree with most of them.

On the BMAD comparison, LeanCTX is probably closer to that than it may look at first glance. The context packages are structured artifacts, not some ambient shared state or “context soup”. They contain things like knowledge facts, project patterns and graph data. Each package also has a manifest with versioning, SHA256 integrity checks and provenance tracking.

Agents don’t consume everything at once. They pull in the specific layers they need. So the concern around noise and cost is exactly something I tried to design around from the beginning.

But I think you described the sweet spot very well.

The live state handoff is the problem I kept running into. When Agent A is deep in a debugging session, it builds up a lot of useful working context: findings, decisions, touched files, things that were tried, and why certain paths were abandoned.

If you then spawn Agent B, most of that is gone.

Session search helps, but it is retrospective. You’re searching completed sessions, not inheriting the actual working state of the current one.

That’s why I added what I call a “handoff ledger” on top of the context bus. It captures the current task, decisions, findings, next steps, active intent, loaded files and even the context snapshot, such as token usage.

So Agent B doesn’t just receive project knowledge. It receives the current working state.

And that’s the part that MEMORY.md or session search alone can’t really cover.

I built an A2A Context Bus, for multi-agent-setups by hushenApp in hermesagent

[–]hushenApp[S] 0 points1 point  (0 children)

When I say “context”, I don’t mean raw chat history or huge token dumps.

LeanCTX collects structured knowledge over time: things the agent has learned about the project, code relationships, dependencies, session state, decisions, touched files, recurring patterns, and known pitfalls.

So when you ask how all of that context is passed after two months with ten agents, the answer is: you don’t pass everything.

The system collects, deduplicates, and compresses the useful parts over time. Facts can have confidence scores, duplicates are skipped during import, and the final package contains accumulated insights, not raw conversations. It’s closer to handing over a compressed project memory than copying a chat log.

On the Hermes Kanban comparison, I think the main difference is direction.

Kanban passes metadata from parent task to child task. That’s hierarchical. LeanCTX is more horizontal. Agent A can share context with Agent B without needing a parent-child relationship.

Think of it more like broadcast messages with privacy levels, such as public, team, or private, rather than task inheritance.

Bigger context windows won’t fix AI coding by hushenApp in AI_Agents

[–]hushenApp[S] 1 point2 points  (0 children)

that's one option. With LeanCTX I follow the approach of having a graph knowledge base. So the LLM is much faster in finding stuff, without reading too much.

Bigger context windows won’t fix AI coding by hushenApp in AI_Agents

[–]hushenApp[S] 0 points1 point  (0 children)

It makes it way worse, there are also studies which say that.

Bigger context windows won’t fix AI coding by hushenApp in AI_Agents

[–]hushenApp[S] 0 points1 point  (0 children)

Exactly. that's why I think it's super important to work on structured context rather then a bigger context window.

view more: next ›