What Is Context as Cursor

<!-- hierarchy:nav -->

Path: OIP › Thinker Reference › Protocol Concepts › What Is Context as Cursor

Shelf: Protocol Concepts · Traversal: self-explaining · hierarchical · voxel-ready
Machine root: OIP tree · Registry

What Is Context as Cursor

§SELF — what-is-context-as-cursor

What this page is: An explanation of why a model's working context should be a moving pointer over information, not a fixed box of text. What it explains: The difference between the "container" model of context (preload everything) and the "cursor" model (discover as you go), and why the cursor model scales better. Why read it: To understand why fixing context size limits what a model can do, and how making context a pointer removes that limit.

What Context as Cursor Is

Context as cursor (not container) is the idea that a model's working context should not be a fixed block of text that fills up. It should be a pointer (cursor) that moves over an unbounded graph of information.

In the container model, you preload everything the model might need into the context window. The model receives a block of text containing instructions, background, and data. When the window fills up, old information is dropped. The model can only work with what fits.

In the cursor model, the model starts with a minimal context — a pointer to a starting node in a graph. As it works, it follows links to discover what it needs. The context is the current position in the graph, not the contents of the graph. The model does not carry the graph; it moves through it.

Why It Matters

The container model has three hard problems:

1. You cannot fit everything. Context windows have finite size (even "large" windows are tiny compared to the information a model might need for complex tasks).
2. You must decide relevance in advance. Someone — usually a human — chooses what to put in the context before the model starts. If that choice is wrong, the model lacks information it needs.
3. Information is lost when dropped. When the window fills, old tokens are discarded. There is no record of what was removed. The model forgets permanently.

These problems are structural. They do not go away with larger windows. A larger box is still a box.

The cursor model solves all three:

1. The graph can be infinite. The model touches only what it needs.
2. The model discovers information as it goes. No advance selection is required.
3. Nothing is lost. The graph keeps everything. The model's path through the graph is recorded.

The Key Idea

Context is not what you have. It is where you are.

In the cursor model, the model receives a starting pointer — a position in a graph of linked information. Each node in the graph contains data and links to other nodes. The model reads the current node, decides what it needs next, and follows a link. Its context is its current position plus the path it took to get there.

Think of reading a book. The container model is like memorizing the entire book before you start. The cursor model is like reading one page and using the page numbers to find the next relevant section. You do not need to hold the whole book in memory. You need to know where you are and how to turn the page.

A graph (a network of nodes connected by links) can be arbitrarily large. The model does not need to know the whole graph. It only needs to know its current node and the links available from that node. The context window holds the cursor position and the local neighborhood — not the entire graph.

What It Got Right

Unbounded scope. Because the graph is not stored in the context window, it can be larger than any context window. The model accesses information by reference (following links), not by value (loading text).

Dynamic discovery. The model finds information when it needs it, not before. If the model encounters a term it does not understand, it follows a link to its definition. It does not need every definition preloaded.

Token efficiency. Tokens are only spent on information the model actually uses. No wasted tokens on irrelevant background material.

Persistence. The graph is permanent. Information is not dropped. The model's path (the sequence of nodes visited) is recorded as a trail of receipts or links, creating an audit trail of what was accessed and when.

Composable contexts. Multiple models can share the same graph, each with its own cursor. One model's discovered path becomes another model's starting point.

What It Got Wrong or Left Unfinished

Graph construction is hard. The cursor model assumes a well-linked graph exists. Building that graph — deciding what the nodes are, what the links mean, and how they connect — is a design problem with no general solution.

Latency compounds. Each link traversal takes time. If a task requires following many links, the total latency (delay from request to response) can exceed what the container model would have incurred by loading everything at once.

Local minima. A model can get stuck in a subgraph (a local region of the graph) and miss relevant information in a distant node with no clear link path. Discovery depends on link quality.

No standard graph format. Unlike context windows (which all major models use similarly), cursor-over-graph implementations vary. There is no universal protocol for how a graph should be structured, linked, or traversed.

How It Connects to Other Ideas

Hypertext and the World Wide Web: The web is a cursor model. A browser starts at a URL (a pointer), loads a page (a node), and follows links to other pages. The browser does not preload the entire web. It fetches what the user requests. Context as cursor applies the same architecture to language models.

Open Invocation Protocol (OIP): OIP implements context as cursor. The model receives a Tap & Go drop (a starting pointer — a URL that identifies an object). It follows links to discover objects. It invokes what it needs. Each invocation produces a receipt that links back to the ledger (a permanent record of all actions). The model's context is the set of receipts it has collected — a trail of pointers — not a fixed block of text.

Database Query Planning: A database query optimizer evaluates different plans for fetching data. It does not load all tables into memory. It uses indexes (pointers) to find relevant rows. Context as cursor applies the same principle: use pointers to access data on demand.

Sources

No single source defines "context as cursor." The idea emerges from multiple traditions:

Bush, Vannevar. "As We May Think." The Atlantic, 1945. (Early vision of linked information traversal.)

Engelbart, Douglas. "Augmenting Human Intellect: A Conceptual Framework." 1962. (First practical system for cursor-based information navigation.)

Berners-Lee, Tim. "Information Management: A Proposal." CERN, 1989. (The document that led to the World Wide Web — a cursor-over-graph system.)

Nelson, Theodor Holm. "Literary Machines." 1981. (The concept of hypertext as a generalized cursor model for information.)

---

Up the tree

• OIP root — protocol root, zero-context entry
• Thinker Reference hub — full hierarchy map
• Protocol Concepts shelf — siblings on this shelf
• Voxel graph article — how pages link as voxels
• Self-describing protocol

Related on this shelf

• What Is Autopoiesis
• What Is Capability-Based Security
• What Is a Capability Token
• What Is a Confused Deputy
• What Is a Convergence Catalogue
• What Is a Falsification Surface
• What Is HATEOAS
• What Is the History of Link Protocols

Machine surfaces

• Public page: https://miscsubjects.com/a/what-is-context-as-cursor
• JSON article: https://miscsubjects.com/api/articles/what-is-context-as-cursor
• OIP ask: https://miscsubjects.com/api/dispatch?ask=What%20Is%20Context%20as%20Cursor