Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • The agent boom has been so good to React Flow.
    by CuriouslyC
  • 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.

    by Edmond
  • 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?

    by jborland
  • Looks great! Signed up but since I mostly use Claude via Claude Code I will wait for the cli implementation with BYOK.
    by Smortaxen
  • Yes! That's top on our priority list - will update when we have added it.
    by jborland
  • Msty has a pretty good interface for this as well. It actually has a ton of qol updates compared to the big webchat interfaces.
    by conception
  • 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!
    by isege
  • Nice! Excited to see what you come up with. Best of luck
    by jborland
  • 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.
    by djgrant
  • 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
    by jborland
  • 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?

    by chaudharyt
  • 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).

    by jborland
  • 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).
    by cootsnuck
  • 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.

    by mdebeer
  • 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.
    by kanodiaayush
  • >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.

    by protocolture
  • 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.

    by mdebeer
  • 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.

    by confusus
  • 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?

    by jborland
  • 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 :)

    by boomskats
  • That sounds super cool, let me add another voice of encouragement, please do publish it.
    by kloud
  • Would love to see that--haven't found a great LLM interface for obsidian yet.
    by heliostatic
  • 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?

    by jborland
  • 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/

    by kloud