Show HN: Git for LLMs – A context management interface
twigg.aiAnyway, great project! Cheers.
Would you prefer a terminal Claude-Code style integration, or would browser based CLI integration work too?
Could you please explain what you mean by "within branch" context switches?
The way Twigg works is you can choose exactly what prompt/output pairs (we call them nodes) are sent to the model. You can move 'nodes' from one branch to another. For example, if you do a bug fix in one branch, you can add the corrected solution as context to another branch by moving the node, whilst ignoring the irrelevant context spent trying to fix the bug.
This way you can specify exactly what context is in each branch.
Wondering why they necessarily have to be on the same git branch?
Take your refactoring example. Start with base branch ‘A’, then for each of the 3 related components, create a new git branch from branch ‘A’.
If we built this on the Twigg interface, would this be useful?
A couple of weeks ago I built something very very similar, only for Obsidian, using the Obsidian Canvas and OpenRouter as my baseline components. Works really nicely - handles image uploads, autolayout with dagre.js, system prompts, context export to flat files, etc. Think you've inspired me to actually publish the repo :)
I definitely think that there is a lot of work to do with context management UX. For us, we use react flow for our graph, and we manage the context and its tree structure ourselves so it's completely model agnostic. The same goes for our RAG system, so we can plug and play with any model! Is that similar for you?
In Solvent, the main utility is allowing forked-off use of the same session without context pollution.
For instance a coding assistant session can be used to generate a checklist as a fork and then followed by the core task of writing code. This allows the human user to see the related flows (checklist gen,requirements gen,coding...etc) in chronological order without context pollution.
Context pollution is a serious problem - I love that you use that term as well.
Have you had good feedback for your fork-off implementation?
Yes it has proven quite a useful feature. Primarily for the reason stated above, allowing users to get a full log of what's going on in the same session that the core task is taking place.
We also use it extensively to facilitate back-and-forth conversation with the agents, for instance a lot of our human-in-loop capabilities rely on the forking functionality...the scope of its utility has been frankly surprising :)
Appreciate the feedback. We agree there's definitely more work to be done on exactly how trees are represented to the user.
When I was using twigg to build itself, I often just used the side panel branch off when I needed to instead of using the tree diagram. The tree then kind of built itself.
Would be interested to hear if you prefer having the tree up on screen, or if you prefer the 'branch to the side' approach.
Very interesting you bring this up. It was quite a big point of discussion whilst jamie and I were building.
One of the big issues we faced with LLMs is that their attention gets diluted when you have a long chat history. This means that for large amounts of context, they often can't pick out the details your prompt relates to. I'm sure you've noticed this once your chat gets very long.
Instead of trying to develop an automatic system to descide what context your prompt should use (I.e which branch you're on), we opted to make organising your tree a very deliberate action. This gives you a lot more control over what the model sees, and ultimately how good the responses. As a bonus, if a model if playing up, you can go in and change the context it has by moving a node or two about.
Really good point though, and thanks for asking about it. I'd love to hear if you have any thoughts on ways you could get around it automatically.
I think in general these things should not be confused to be the one and same artifact - that of a personal memory device and that for LLM context management. Right now, it seems to double up, of which the main problem is that it kind of puts the burden on me to manage my memory device, which should be automatic I think. I don't have perfect thoughts on it, so I'll leave it at this, its work in progress..
is the expectation that you will be running many branches of of context at the same time?
Completely subjectively, for me its both. I have several Chat GPT tabs where it is instructed not to respond, or to briefly summarise. System works both ways imho.
... though I honestly do wish that the current LLM interfaces I use would just implement something like this. Maybe they could acquire you guys :D
I wanted to try something like this from a while. Was excited to see maxly.chat's promotion on X but was disappointed it wasn't ready.
On a side note, do you also have zero data retention agreements with the providers?
Regarding data agreements, we have the standard 'enterprise' agreement with the providers, which is that none of your data will be used for training purposes, and will be deleted after a standard specified time window (30 days).
---
[1] *Mind Map Format Overview* - A graph-based documentation format stored as plain text files where each node is a single line. The format leverages LLM familiarity with citation-style references from academic papers, making it natural to generate and edit [3]. It serves as a superset structure that can represent trees, lists, or any graph topology [4], scaling from small projects (<50 nodes) to complex systems (500+ nodes) [5]. The methodology is fully detailed in PROJECT_MIND_MAPPING.md with bootstrapping tools available at https://gist.github.com/horiacristescu/7942db247fdfb31d7150b....
[2] *Node Syntax Structure* - Each node follows the format: `[N] *Node Title* - node text with [N] references inlined` [1]. Nodes are line-oriented, allowing line-by-line loading and editing by AI models [3]. The inline reference syntax `[N]` creates bidirectional navigation between concepts, with links embedded naturally within descriptive text rather than as separate metadata [1][4]. This structure is both machine-parseable and human-readable, supporting grep-based lookups for quick node retrieval [3].
[3] *Technical Advantages* - The format enables line-by-line overwriting of nodes without complex parsing [2], making incremental updates efficient for both humans and AI agents [1]. Grep operations allow instant node lookup by ID or keyword without loading the entire file [2]. The text-based storage ensures version control compatibility, diff-friendly editing, and zero tooling dependencies [4]. LLMs generate this format naturally because citation syntax `[N]` mirrors academic paper references they've seen extensively during training [1][5].
[4] *Graph Topology Benefits* - Unlike hierarchical trees or linear lists, the graph structure allows many-to-many relationships between concepts [1]. Any node can reference any other node, creating knowledge clusters around related topics [2][3]. The format accommodates cyclic references for concepts that mutually depend on each other, captures cross-cutting concerns that span multiple subsystems, and supports progressive refinement where nodes are added to densify understanding [5]. This flexibility makes it suitable as a universal knowledge representation format [1].
[5] *Scalability and Usage Patterns* - Small projects typically need fewer than 50 nodes to capture core architecture, data flow, and key implementations [1]. Complex topics or large codebases can scale to 500+ nodes by adding specialized deep-dive nodes for algorithms, optimizations, and subsystems [4]. The methodology includes a bootstrap prompt (linked gist) for generating initial mind maps from existing codebases automatically [1]. Scale is managed through overview nodes [1-5] that serve as navigation hubs, with detail nodes forming clusters around major concepts [3][4]. The format remains navigable at any scale due to inline linking and grep-based search [2][3].
I find most need for managing context for problem solving. I describe a problem, LLM gives me 5 possible solutions. From those I immediately see 2 of them won't be viable, so I can prune the search. Then it is best to explore the others separately without polluting the context with non-viable solutions.
I saw this problem solving approach described as Tree-based problem management [0]. Often when solving problems there can be some nested problem which can prove to be a blocker and cut off whole branch, so it is effective to explore these first. Another cool attempt was thorny.io [1] (I didn't get to try it, and it is now unfortunately defunct) in which you could mark nodes with metadata like pro/con. Higher nodes would aggregate these which could guide you and give you prioritization which branch to explore next.
Also graph rendering looks cooler, but outliners seem to be more space efficient. I use Logseq, where I apply this tree-based problem solving, but have to copy the context and response back-and-forth manually. Having an outliner view as an alternative for power users would be neat.
[0] https://wp.josh.com/2018/02/11/idea-dump-2018/#:~:text=Tree-... [1] https://web.archive.org/web/20240820171443/http://thorny.io/