View Markdown

Vifu core runtime design

Status: Available. This page describes behavior implemented in the open-source Vifu runtime today.

Vifu uses one App-centered invocation model in two shapes. An application can embed VifuRuntime and call it directly, or use Vifu Server for stable App APIs, authorization, database persistence, and traces. The application continues to own its interface and interaction design.

Running components

Embedded

Architecture diagram
Rendering diagram

One embedded Runtime represents one App. It registers providers, Agents, and named endpoints dynamically, keeps independent session state, and supports async or non-blocking start/poll/cancel invocation.

Service

Architecture diagram
Rendering diagram
  • VifuRuntime supplies the provider, Agent, endpoint, session, timeout, cancellation, and result semantics used by embedded hosts and Server.
  • Vifu Server authorizes App requests, resolves Agents, and stores Apps, keys, provider configuration, and traces.
  • Vifu Agent Gateway is an optional remote provider transport. It connects to Server; several Gateways can serve the same deployment.
  • PostgreSQL keeps operational state across Server restarts.
  • Operations Console configures and inspects the same APIs used by other clients.

How an Agent request runs

  1. The client sends an App key and an Agent identifier.
  2. Vifu Server checks the key's App and permissions.
  3. The Server builds the selected Runtime provider, Agent, and endpoint contract.
  4. Runtime invokes the configured provider directly or through Agent Gateway.
  5. Vifu Server returns the result and records the trace.

Changing the provider or Gateway does not require the client to change its App URL.

Public App APIs

APICurrent purpose
/v1/modelsList Agents exposed by the App selected by the App key.
/v1/chat/completionsCall an Agent in that App with an OpenAI-compatible request.
/{app-slug}/v1/audio/speechGenerate speech through a configured capability.
/{app-slug}/v1/audio/transcriptionsTranscribe audio through a configured capability.
/{app-slug}/v1/realtimeOpen the App's realtime connection.
/{app-slug}/v1/rpcReach an attached application runtime extension.

The RPC route is available only when an operator has attached a runtime extension to that App. Vifu does not invent the extension's application language or editor format.

Runtime extension boundary

Architecture diagram
Rendering diagram

Runtime extensions use ordinary HTTP and JSON-RPC. Vifu Server remains the authority for App identity, exposed Agents, launch channels, and traces. Read Runtime extensions for this boundary.

Embedded Runtime API

The public vifu-runtime crate provides VifuRuntime, AgentProvider, dynamic Agent and endpoint registration, session state, host-provided storage, portable snapshots, async invocation, and a start/poll/cancel game-loop API. The mobile UniFFI surface exposes the same shape to iOS and Android hosts.

The lower-level API provides headless command, event, effect, state, and snapshot primitives with a standard Bevy Plugin extension point. An application can combine both levels and define its own behavior.

The crate is not a built-in story language, visual editor, or published release format. Those application-specific concepts belong to the plugin or external runtime that implements them.

Read Technical direction for work that is not yet part of the supported contract.