[HN Gopher] Show HN: Git for LLMs - a context management interface
___________________________________________________________________
Show HN: Git for LLMs - a context management interface
Hi HN, we're Jamie and Matti, co-founders of Twigg. During our
master's we continually found the same pain points cropping up when
using LLMs. The linear nature of typical LLMs interfaces - like
ChatGPT and Claude - made it really easy to get lost without any
easy way to visualise or navigate your project. Worst of all, none
of them are well suited for long term projects. We found ourselves
spending days using the same chat, only for it to eventually break.
Transferring context from one chat to another is also cumbersome.
We decided to build something more intuitive to the ways humans
think. We started with two simple ideas. Enabling chat branching
for exploring tangents, and an interactive tree diagram to allow
for easy visualisation and navigation of your project. Twigg has
developed into an interface for context management - like "Git for
LLMs". We believe the input to a model - or the context - is
fundamental to its performance. To extract the maximum potential of
an LLM, we believe the users need complete control over exactly
what context is provided to the model, which you can do using
simple features like cut, copy and delete to manipulate your tree.
Through Twigg, you can access a variety of LLMs from all the major
providers, like ChatGPT, Gemini, Claude, and Grok. Aside from a
standard tiered subscription model (free, plus, pro), we also offer
a Bring Your Own Key (BYOK) service, where you can plug and play
with your own API keys. Our target audience are technical users
who use LLMs for large projects on a regular basis. If this sounds
like you, please try out Twigg, you can sign up for free at
https://twigg.ai/. We would love to get your feedback!
Author : jborland
Score : 41 points
Date : 2025-10-23 15:12 UTC (7 hours ago)
(HTM) web link (twigg.ai)
(TXT) w3m dump (twigg.ai)
| djgrant wrote:
| 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:
| 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
| confusus wrote:
| 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:
| 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:
| 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:
| 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.
| boomskats wrote:
| 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
| :)
| jborland wrote:
| 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?
| Edmond wrote:
| we implemented a similar idea some time back and it has proven
| quite useful: https://blog.codesolvent.com/2025/01/applying-
| forkjoin-model...
|
| 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.
| jborland wrote:
| 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:
| 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 :)
___________________________________________________________________
(page generated 2025-10-23 23:00 UTC)