Skip to main content
A node is one message on the canvas. User messages, assistant replies, and in-progress drafts all behave like nodes in the graph. Most NodePad actions start by selecting a node or branching from one.

​
What a node carries

Message content

Rendered as Markdown — lists, code blocks, links — so the message stays readable inside the graph.

Attachments

Uploaded files, images, and tool-call artifacts that stay part of the node’s context footprint.

Model metadata

Assistant nodes show which model produced the reply. References can also live on a node — the visible @ token is only the UI layer; the cross-message link is stored separately.

​
How nodes become branches

Nodes connect in sequence. Each link forward is a . When you branch from a node, NodePad creates a new path from that point — a — without changing the original branch.

​
What you can do from a node

Branch

Start a new path from the exact context at that point.

Edit or re-run

Available depending on the node type and position.

Reference or merge

Pull this node into another message through an @ reference or a merge flow.

​
Behaviors worth knowing

Branching does not rewrite the original path. It creates a new one.
Mentioning @B1-2 in text is not enough on its own. The reference picker records the actual linked node so NodePad knows what to include.
You can copy a node ID from the context menu. That is handy when you want to reference a specific message cleanly.
Text notes are not conversation nodes. They are standalone annotations on the canvas.
If you are unsure whether a follow-up belongs in the current branch, branch first. It is cheaper to keep two clean paths than to untangle one noisy one later.

​
Continue

Forking

When and how to branch.

References

How @ works across branches.