_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Show HN: Git for LLMs â A context management interface
isege wrote 6 hours 11 min ago:
I'm also developing a similar branching interface though mine is
structured differently. I hope we can make a dent in the LLM space,
best of luck!
jborland wrote 5 hours 27 min ago:
Nice! Excited to see what you come up with. Best of luck
Smortaxen wrote 7 hours 3 min ago:
Looks great! Signed up but since I mostly use Claude via Claude Code I
will wait for the cli implementation with BYOK.
jborland wrote 6 hours 47 min ago:
Yes! That's top on our priority list - will update when we have added
it.
chaudharyt wrote 7 hours 33 min ago:
Interesting to see a productionized version of this interface!
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?
jborland wrote 6 hours 48 min ago:
Thanks! We've been working on this since July - we found it takes
quite a while to get something from idea stage to an actual
production version.
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).
kloud wrote 9 hours 29 min ago:
Great work! I was just thinking the other day how an interface like
this would be useful, it seems strange we don't see more UI attempts
beyond basic linear chat.
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] [1]
HTML [1]: https://wp.josh.com/2018/02/11/idea-dump-2018/#:~:text=Tree-ba...
HTML [2]: https://web.archive.org/web/20240820171443/http://thorny.io/
pu_pu wrote 9 hours 30 min ago:
Is it open source?
jborland wrote 6 hours 46 min ago:
Not currently, sorry. But you can sign up and use it for free, with
paid options for higher rate limits and better models.
joshdavham wrote 15 hours 28 min ago:
Best of luck to you two! This is definitely a problem worth solving
... 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
jborland wrote 6 hours 46 min ago:
Thanks! We can hope ;)
conception wrote 15 hours 34 min ago:
Msty has a pretty good interface for this as well. It actually has a
ton of qol updates compared to the big webchat interfaces.
CuriouslyC wrote 16 hours 14 min ago:
The agent boom has been so good to React Flow.
visarga wrote 16 hours 28 min ago:
I am using a graph based format which is stored as text file. It is as
simple as possible: each node is a line, prefixed with node id, and
containing inline node references. I am providing a sample right here:
--- [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 [1] .
[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] *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].
HTML [1]: https://gist.github.com/horiacristescu/7942db247fdfb31d7150b19...
kanodiaayush wrote 17 hours 33 min ago:
I tried it, I have tried a very similar but still different use case. I
wonder if you have thoughts around how much of this is our own context
management vs context management for the LLM. Ideally, I don't want to
do any work for the LLM; it should be able to figure out from chat what
'branch' of the tree I'm exploring, and then the artifact is purely for
one's own use.
protocolture wrote 13 hours 52 min ago:
>I tried it, I have tried a very similar but still different use
case. I wonder if you have thoughts around how much of this is our
own context management vs context management for the LLM.
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.
mdebeer wrote 16 hours 34 min ago:
Hi, matti here.
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.
kanodiaayush wrote 12 hours 1 min ago:
I also realised I forgot to commend you; I think this is a useful
interface! Kudos on building it! I'm working on something very
related myself.
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..
8note wrote 15 hours 46 min ago:
something im wondering is, suppose you add or remove a chunk of
context - what do you do to evaluate whether thata better or not,
when the final resulting code or test run might be half an hour or
an hpur later?
is the expectation that you will be running many branches of of
context at the same time?
cootsnuck wrote 17 hours 40 min ago:
Yea, this really needed to happen. Idk if this specific branching type
of interface will stand the test of time, but I'm glad to see people
finally braving beyond the basic chat interface (which I think many of
us forget was only ever meant to be a demo...yet it remains default and
dominant).
mdebeer wrote 16 hours 26 min ago:
Hi, matti here.
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.
Edmond wrote 20 hours 8 min ago:
we implemented a similar idea some time back and it has proven quite
useful: [1] 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.
HTML [1]: https://blog.codesolvent.com/2025/01/applying-forkjoin-model-a...
jborland wrote 20 hours 2 min ago:
Great to hear others are thinking along similar lines!
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?
Edmond wrote 19 hours 33 min ago:
Feel to "borrow" the term "context pollution" :)
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 :)
boomskats wrote 20 hours 33 min ago:
Ha! This looks really nice, and I'm right there with you on the context
development UX being clunky to navigate.
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 :)
kloud wrote 9 hours 23 min ago:
That sounds super cool, let me add another voice of encouragement,
please do publish it.
heliostatic wrote 16 hours 57 min ago:
Would love to see that--haven't found a great LLM interface for
obsidian yet.
jborland wrote 20 hours 15 min ago:
That's great to hear! Best of luck with it, let me know how it goes.
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?
confusus wrote 22 hours 7 min ago:
Really cool! Iâd want something like this for Claude code or other
terminal based tools. Basically when working on code sometimes I
already interrupt and resume the same session in multiple terminals so
I can explore different pathways at the same time without the parallel
sessions polluting one another. Currently this is really clunky in
Claude Code.
Anyway, great project! Cheers.
jborland wrote 21 hours 54 min ago:
Thanks! I totally agree, we want to add CLI agent integration! I
often use Gemini CLI (as it's free), and it's so frustrating not
being able to easily explore different tangents.
Would you prefer a terminal Claude-Code style integration, or would
browser based CLI integration work too?
captainkrtek wrote 21 hours 26 min ago:
Imo Iâd prefer terminal for this as well. Ie; if I could keep
context specific to a branch, or even within a branch switch
contexts.
jborland wrote 21 hours 17 min ago:
Thanks for the feedback. We will add in CLI integration soon!
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.
captainkrtek wrote 2 hours 36 min ago:
Sure, currently Iâm performing a big refactor. As I do this,
I find myself switching between refactoring perhaps 2-3 related
(but still separate) components in my code. I find claude
struggles to separate them if Iâm working on one then need to
switch tracks. Being able to contain the work on each part (all
within the same git branch) but in separate contexts, may be
helpful to prevent misinterpretation.
djgrant wrote 1 day ago:
This is an interesting idea. Have you considered allowing different
models for different chat nodes? My current very primitive solution is
to have AI studio on one side of my screen and ChatGPT on the other,
and me in the middle playing them off each other.
jborland wrote 1 day ago:
Yes, you can switch models any time for different chat nodes. So you
can have different LLM review each others work, as an example. We
currently have support for all the major models from ChatGPT, Gemini,
Claude and Grok. Hope this helps
DIR <- back to front page