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!

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] https://wp.josh.com/2018/02/11/idea-dump-2018/#:~:text=Tree-... [1] https://web.archive.org/web/20240820171443/http://thorny.io/

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 :)

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.

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.

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).

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?

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.

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!

Msty has a pretty good interface for this as well. It actually has a ton of qol updates compared to the big webchat interfaces.

Looks great! Signed up but since I mostly use Claude via Claude Code I will wait for the cli implementation with BYOK.

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.

The agent boom has been so good to React Flow.

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 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].

Is it open source?

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