One Chat, Many Models, Every Path Preserved: Open-Source AIbranch Rebuilds the AI Conversation as a Branching Tree

Every mainstream AI chatbot still runs on a single rail. You type, the model replies, and the exchange stacks up in one unbroken column, no matter how tangled the thinking behind it becomes. A newly published open-source platform called AIbranch sets out to break that column apart. Developed by Jin-Dong Kim of Japan’s Database Center for Life Science and described in the journal SoftwareX, the system treats a conversation as a tree rather than a list: any turn can be forked into parallel branches, models from rival providers can take over the same thread mid-stream, and the entire branching structure is rendered on screen as a navigable workspace. Context travels with it, so a question posed to one model can be answered, appraised or extended by another without the thread ever being abandoned. The full stack — chat interface, backend hub and three reusable engines — is released under the Apache License 2.0, with source code available at https://github.com/jdkim/llm_meta_chat and a citable archival capsule on Zenodo.

The problem, Kim argues, is architectural rather than cosmetic. Comparing answers while keeping the alternatives alive is, by its nature, a tree-shaped behavior — but the dominant chat paradigm exposes only a list-shaped data model, and users have long paid the difference out of pocket across browser tabs, copy-paste documents and personal notes that the chat tool itself never remembers. The fork buttons now appearing in commercial products fall short in a specific, structural way. A fork taken from ChatGPT stays on OpenAI’s models; a fork taken from Gemini stays on Google’s; and each fork opens as a separate chat rather than a sibling inside a single workspace. Anyone wanting to compare two providers’ answers to the same question must run parallel conversations and ferry context between them by hand. Anyone wanting a specialist model for one step of a broader task — retrieval grounding from one model, careful reasoning from another, polished presentation from a third — must stage the work across separate chats that share nothing.

AIbranch’s answer begins in the database, not the interface. Every conversational turn — one user prompt and the model’s response — is stored as a record carrying a pointer to the turn it originated from. A branch, in this scheme, is simply a new turn that shares a parent pointer with an existing sibling; the tree shape emerges directly from the data model instead of being simulated by interface arrows. A History pane lays the full genealogy out as a vertical, chronologically ordered list of prompts, with arcs tracing each branch’s lineage, and any earlier turn remains navigable and reusable as context for any path. The paper compresses the design stance into a single chain of logic: to compare answers from different models you must keep both; to keep both, you must branch; and to navigate what you have kept, the tree must be visible. The tree is a first-class citizen of the interface, not an easter egg hidden behind per-message arrows.

The platform’s second defining move is the mid-thread model handoff. A selector exposes models from every configured provider — OpenAI, Anthropic, Google and locally hosted models served through Ollama — and switching mid-conversation does not open a new chat: the system replays prior context to whichever model the user selects, so a Claude turn can naturally follow a Gemini turn that grounded the discussion in live web search. Provider-native tools such as web search and URL grounding attach implicitly, turn by turn, to whichever model is active, with no toggle for the user to manage. Capability flags on each model — covering vision, function calling and image generation — adapt the interface automatically, hiding the image-attachment control when a model cannot see pictures. Images generated through Google’s Gemini image-generation family appear inline as ordinary turns, subject to the same branching, history and export mechanics as any text response.

Beneath the surface sits a five-component architecture that separates concerns which commercial products fuse together. A deliberately thin chat application hosts the user-facing interface; a backend hub is the only component in the entire stack that talks to provider APIs, exposing a uniform interface to OpenAI, Anthropic, Google and Ollama while holding per-user credentials encrypted at rest with Amazon Web Services’ Key Management Service; and three mountable Ruby on Rails engines supply the client plumbing, chat management and the prompt-execution tree that underlies branching. Security is two-layered: end users sign in through Google OAuth2, and the chat service authenticates to the hub on every request with a Google ID token verified against a configurable allow-list, so new client services can attach to the same hub with a configuration change and users gain single sign-on across them. Responses stream end-to-end over Server-Sent Events, from provider through hub and chat service into the browser.

The hub is also where tool integration lives, and the placement is deliberate. The Model Context Protocol, the fast-spreading standard that lets models invoke external tools, is normally wired into each chat application separately, with every installation maintaining its own registrations. AIbranch installs it one layer deeper: the hub itself acts as the protocol client, so any frontend built on the hub inherits the same tool set across every model the user selects. Users register tool servers in their hub settings, keep them private or publish them for others, then choose which servers to activate per chat and which tools to expose per prompt. When a model issues a tool call, the interface surfaces the invocation, the hub executes it against the registered server, and the result returns to the model. A biomedical dictionary server makes it concrete: a researcher can ask, in plain conversation, for the gene ontology identifier of cell migration and receive the resolved identifier inline.

Handing a thread between models raises a quieter engineering question: how much history does each new model actually receive? AIbranch’s answer is a cost-driven compromise. Walking back along the current branch, the system replays recent turns verbatim up to a configurable threshold — ten by default — and compresses everything older into a single context-priming summary. The summariser is pinned to a small, cheap model rather than the user’s currently selected one, decoupling the cost and latency of summary generation from the active conversation. The paper names the trade-offs candidly: a cheap summariser caps summary fidelity, so a summary that drops a load-bearing earlier turn can make the chosen model drift subtly on later turns, and compressing history into one message sacrifices provenance, since the model can attribute its output only to the summary rather than to specific turns. Users who prefer completeness can raise the threshold and skip summarisation entirely, or select a stronger summariser where deployment policy allows.

The security analysis is unusually frank for a research release. Each provider receives only the current prompt plus the carried-over context; providers never see traffic addressed elsewhere, never see previous sessions, and share no state through the hub — a provider receiving a mid-conversation baton sees rival-generated turns, but never rival credentials, tools or system state. The trust boundary for external tools is the registered URL, with no sandbox around the third-party service; only model-constructed tool arguments are forwarded, never full history or credentials. The paper also documents what the current release lacks: audit logging of provider calls, per-tool rate limits, content inspection of tool responses — the last leaving an indirect prompt-injection surface if a tool server turns malicious — and network-layer URL allow-listing, whose absence leaves a server-side request forgery surface. Cancellation of a streaming reply propagates symmetrically up the stack, and partial output is persisted so the saved record matches exactly what the user saw.

A worked example shows the machinery in motion. A researcher probing contested links between glycans — complex sugars implicated in disease — first asks Gemini to gather recent literature and web evidence, with search grounding attached automatically. Switching to a small, locally hosted Qwen model, cheap and fast, the researcher requests a critical appraisal of the gathered material. Unsatisfied, they return to the gathering turn in the History pane, fork the thread, switch to Anthropic’s Claude and re-ask the identical question — leaving two independent appraisals coexisting as sibling branches over the same evidence. From Claude’s branch, the researcher asks Qwen to extract the appraised findings as structured JSON with grounded identifiers, a step that invokes the dictionary-resolution tool server, then switches to ChatGPT to draft candidate hypotheses with rationale. Five prompts, four models, one conversation, full provenance preserved — and nothing automated: every fork, every handoff and every tool invocation is a human choice, not a planner’s decision. If a step disappoints, forking at that point retries it without discarding the work that fed it.

Kim is careful about where the system sits in a crowded field. Mainstream services conceal branching behind per-turn arrows and confine forks to a single provider; open-source frontends such as LibreChat, Open WebUI and big-AGI offer multi-provider access and pieces of branching or tool integration, but present branches as separate threads or per-message controls; API aggregators route queries but hold no conversation; and Loom, the one adjacent system with a first-class visible tree, is single-provider and built for creative writing. Within the chat-interface category, the paper states, AIbranch is to the author’s knowledge the only system that exposes the conversation tree as a first-class navigable interface — the visibility being what makes cross-provider handoff and shared tools genuinely usable. Supported by Japan’s Ministry of Education, Culture, Sports, Science and Technology, the work is framed as an enabling contribution rather than a measured speedup and doubles as the substrate for an ongoing usability study. Planned next: hub-level “skills” above tool integration, a growing provider catalog, and a debate over whether the tree should eventually loosen into a directed acyclic graph in which single turns draw on multiple predecessors — an idea deferred until its payoff justifies the complexity.
Subject of Research: An open-source software platform, AIbranch, for branched multi-model large language model (LLM) conversations, built around a visible conversation-tree data model, in-thread cross-provider model handoff, context summarization, and hub-level Model Context Protocol (MCP) tool integration.
Article Title: AIbranch: A platform for branched multi-model LLM conversations
Article References: Kim, J.-D. (2026). AIbranch: A platform for branched multi-model LLM conversations. SoftwareX, 35. https://doi.org/10.1016/j.softx.2026.102983
Image Credits: AI Generated
DOI: 10.1016/j.softx.2026.102983
Keywords: large language models, conversation branching, multi-model chat, Model Context Protocol, conversation tree, cross-provider handoff, open-source software, Ruby on Rails, context summarization, prompt navigation, server-sent events, human-AI interaction