"Manipulate Code through the Graph" - Feature

[DeusData]

Hey guys,

I am currently thinking about adding some functionality to the MCP which would allow directly manipulating the graph nodes, which are connected to your code files. Through that you would also shape the code itself on your filesystem, effectively making CBM a complete read/write infrastructure on top of your code. This likely would safe some roundtrips and input tokens, as the agent will only need to understand the dependencies of the code through the graph and will then directly only write on those nodes which he wants to change (which then through the database translate over to your actual code files async in the background).

What do you think of this? It is currently kinda only a thought experiment of mine. Would really appreciate your opinions :)

[codeliftsleep2]

I've got something similar built out here (I think, based on what I am understanding at least) as a full Compiler-IR, micro-opcode encoding, structured transport protocol that compresses what is being sent into an ultra-compact form and then decompresses the output. Also includes a delta transport layer that updates only the changes rather than the entire file. These two projects would work extremely well together, as they tackle different problems, but in a very complementary way.

https://github.com/codeliftsleep2/Clean-CTX

[DeusData]

Sounds nice, will have a look

[codeliftsleep2]

Awesome. I've just created a full integration between CBM and Clean-CTX. It auto-detects whether CBM is installed, launches it as a managed subprocess, and intercepts the raw response from CBM's stdout before it reaches the LLM, then compresses it into a clean, structured Ultra-Compact form prior to sending it through.

Clean-CTX also has a cbm_proxy MCP tool that lets the agent query CBM directly through Clean-CTX, with the compression happening transparently on the way back.

Agent → cbm_proxy tool → CBM subprocess → raw stdout → Clean-CTX intercepts → Ultra-Compact compression → Agent

A few thoughts on where this could go further:

The current integration compresses CBM's output after the fact, but the greater opportunity lies in using CBM's graph intelligence to make Clean-CTX's compression smarter.

Specifically:

• Adaptive fidelity from graph importance. CBM already scores symbol importance across the call graph. I'm building a PageRank layer into Clean-CTX that applies adaptive fidelity per symbol rather than uniformly per file. CBM's importance scores are a natural seed for that; the most-connected nodes in your graph become the highest-fidelity symbols in my compressed output. The two systems reinforce each other.
• Blast radius → delta scoping. When a file changes, CBM's impact analysis already knows which symbols are affected across the codebase. I'm building a blast radius layer in Clean-CTX that automatically includes skeleton summaries of affected files in the delta output. Using CBM's traversal for this instead of my own IR graph means we get your 158-language coverage for free, including cross-service HTTP route impact that my IR graph can't see.
• Cross-language symbol deduplication. Clean-CTX already maintains a global Huffman-coded symbol table across TypeScript, C#, Java, and Rust simultaneously. Symbols that appear across language boundaries, a Java Spring service and its TypeScript Angular client sharing the same domain model names, or a C# API and its Java consumer using the same DTO names, get shorter Huffman codes automatically because they appear more frequently in the unified global table. CBM's cross-language graph traversal could surface which symbols are genuinely cross-language, so the deduplication is semantically informed rather than just frequency-based. Right now, we catch it by coincidence of name frequency. With CBM's graph, we'd catch it by the actual relationship.

The way I see it:
CBM answers what matters and how it connects, Clean-CTX answers how to send that to the LLM as cheaply as possible. The more tightly those two talk, the better both get.

Would love to know if there are query interfaces or graph export formats on your side that would make the deeper integration cleaner. I'd be very happy to build toward whatever is most natural from CBM's architecture.

[DeusData]

Interesting thoughts. Will come back to it, once I managed the current project load. Thanks a lot!

[DeusData]

Thank you for the detailed Clean-CTX follow-up. Output compression and writing source through graph operations are separate proposals, and the integration you describe has not been validated by this project in this thread. I do not have a new design decision or supported export contract to promise here. No further implementation work is being requested while that direction remains undecided.