Hyperspace: More Nodes Is All You Need

What would a chat experience look like if the inference came from another person’s computer? Nicolas Schlaepfer introduces Hyperspace as a decentralized AI network built from resources contributed by a community of personal-computer owners. He describes the organization as having no GPUs of its own. Its existing AI OS application, available for Windows and Mac, uses llama.cpp for inference: in his example, a user could download the application and chat using inference supplied by someone in Belgium.

The next step is to make that network useful across different kinds of work. Schlaepfer’s premise is that a mixture of expert models can provide a better AI experience than relying on one large closed-source model. That preference for diversity becomes a concrete design choice in the workflow demonstrated later: different models receive different jobs.

The new product, also called Hyperspace, is intended to run on that network. It combines prompt engineering, a visual interface built with React Flow, Python execution, and RAG-like web browsing. The interface puts a graph of tasks beside generated explanations and code, making the intermediate work visible rather than presenting only a final chat response.

Planning starts with a fine-tuned model. A user submits a query, and the model produces a directed acyclic graph, or DAG, represented as JSON. The graph expresses a methodical plan: distinct tasks connected into a workflow, with no dependency cycle that leads back to an earlier task. This structured output gives the interface something it can display and let the user edit.

Web extraction supplies another primitive. Hyperspace uses Puppeteer and Beautiful Soup in its in-house scraping pipeline, converting website HTML into Markdown that is easier for an LLM to consume. The node editor and terminal then give power users direct access to the workflow. Individual React Flow nodes generated by the orchestration model can be changed to fit the task.

The early demo begins with a sample query. After submission, the application opens the node editor, where HyperEngine V3, the DAG orchestration model, streams in the plan node by node. Generation produces an editable working surface; the user does not have to accept the plan unchanged.

Before execution, the user can revise three parts of each node:

• Title: the name of the task.
• Task description: what the node should do.
• Expected output: what the node should produce.

The user can also add as many nodes as needed. These controls expose both the work requested and the intended result, so a generated plan can be adjusted before it is run.

Selecting Execute produces an output for each node. Each node creates a query based on its task, combining three sources of context: the overall goal, the local goal, and what happened in the previous node. The overall goal keeps the task connected to the user’s request; the local goal specifies the current work; the previous result carries information forward.

For example, a Python-learning workflow could carry an earlier explanation of functions into a task about reduce. The query-building pattern can be expressed directly in Python:

def build_node_query(overall_goal: str, local_goal: str,
                     previous_output: str) -> str:
    return "\n\n".join([
        f"Overall goal:\n{overall_goal}",
        f"Current task:\n{local_goal}",
        f"Previous node output:\n{previous_output}",
    ])

query = build_node_query(
    overall_goal="Teach Python functions through worked examples.",
    local_goal="Explain reduce with an example that sums integers.",
    previous_output="A function takes inputs and returns a result.",
)
print(query)

This constructs the next query; it does not execute the task. The mechanism is the explicit combination of shared purpose, current instructions, and prior output.

The demo assigns reasoning and summarization to separate models:

Schlaepfer credits this combination with providing diverse synthesized answers. He does not specify the Qwen2 size or the exact Llama variant; the linked Llama card documents the instruction-tuned variant. In the displayed result, the graph remains visible beside generated Python explanations and code, including a reduce example and an explanation of object-oriented programming.

When a node’s output contains Python, the user can run it and inspect the result in the terminal. The terminal opens automatically with the output, extending the workflow from generating code to executing it inside the product.

Schlaepfer presents these capabilities as groundwork for future agentic behavior. The runtime also exposes a virtual file system on the right, where the user can change directories. The intended set of agent primitives comprises memory, Python execution, planning, and code generation. The demonstrated editor, outputs, terminal, and file tree make those foundations tangible, while broader agentic behavior remains the direction of development.

The recorded demo closes with a release forecast of the coming weeks. Back onstage, Schlaepfer narrows that forecast to later that week through a waitlist and directs the audience to the Hyperspace AI Twitter account for updates. This is the historical announcement at the June 2024 AI Engineer World’s Fair, rather than a statement of present availability.