wire-pod — The Local Cloud Replacement

6.1 The Gap That Needed Filling

Vol 4 documented what the DDL cloud was and what its shutdown destroyed: the voice path — the speech-to-text, intent-dispatch, and knowledge-graph layer that processed every “Hey Vector” command and returned an answer to the robot. The onboard Snapdragon APQ8009, the navigation stack, the sensor suite, the animation engine — all of that survived intact. What was gone was the remote server the robot talked to, and without that server a Vector could wander the desk indefinitely but could not execute a voice-initiated action or answer a spoken question (Wikipedia; vector-cloud; wiki.thedroidyouarelookingfor.info; iFixit).

The community answer to this gap is wire-pod, a free open-source local server that fully replaces the defunct DDL cloud — and, with it, DDL’s own paid local alternative, Escape Pod — on Vector 1.0 and Vector 2.0, including unmodified retail robots (wire-pod README/wiki). This volume documents wire-pod in reference depth: its architecture, its speech and intelligence options, its web interface, its extensibility, and why it is the decisive step from “robot whose vendor is gone” to “robot that fully works.”

6.2 What wire-pod Is

Wire-pod is a locally-hosted server, authored by the open-source developer known as kercre123 and maintained by the community, that presents itself to a Vector robot as a replacement for the DDL cloud infrastructure (wire-pod README/wiki). The robot connects to wire-pod instead of DDL’s endpoints; from the robot’s perspective, the local machine running wire-pod is the cloud, and all voice-path processing — wake-phrase response, speech recognition, intent handling, and answer delivery — occurs on that machine rather than on a vendor’s remote server (wire-pod README/wiki).

Wire-pod is built on DDL’s own open-sourced chipper voice backend (see Vol 4), meaning it speaks the same gRPC/TLS protocol the original cloud used — the ProcessIntent endpoint and its associated interface definitions carry over unchanged (github.com/digital-dream-labs/ chipper). Wire-pod adds what the bare chipper reference implementation lacked: a working speech-to-text layer, intent-handling logic, a knowledge-graph or language-model backend, and the tooling to connect a retail robot to a local server (wire-pod wiki).

The project’s scope is deliberately whole: wire-pod does not patch one capability; it replaces the entire voice infrastructure. A Vector running against wire-pod can hear “Hey Vector,” have the audio recognised locally, have the intent resolved by a local or API-backed language model, and hear the answer spoken — all without any DDL infrastructure in the path (wire-pod README/wiki).

6.3 The Foundation: chipper

Wire-pod’s compatibility with an unmodified Vector robot rests on DDL’s decision to release chipper — the voice backend used by the original cloud — as an open-source reference implementation under an MIT license (github.com/digital-dream-labs/chipper). Chipper defines a gRPC/TLS interface with a ProcessIntent endpoint; the robot’s onboard processes (vic-cloud and vic-gateway, distributed by DDL in the vector-cloud repository) know exactly how to speak to this interface (github.com/digital-dream-labs/vector-cloud; chipper). Wire-pod implements a server that fulfills this interface, so the robot does not detect any difference — it sees the same protocol shape it was built to address (wire-pod wiki).

The MIT license on chipper is what made this community use legally straightforward: the community could study the interface definitions, build a compatible server, and distribute it freely without reverse-engineering the original closed binary. The critical detail in chipper’s public release is also its gap: the reference implementation shipped with no built-in speech-to-text engine and no natural-language understanding logic (see Vol 4). Wire- pod’s contribution is filling that gap with a configurable set of STT and intelligence backends, described in the sections that follow.

6.4 Reaching an Unmodified Robot: the “ep” Firmware Variant

One of wire-pod’s most significant properties is support for unmodified retail Vector robots — a qualification that distinguishes it from a developer-only tool. An unmodified retail Vector ships with production firmware that points the robot at DDL’s cloud endpoints. Redirecting this robot to a local server requires a firmware change, but the robot does not need to be unlocked at the level that OSKR provides (Vol 5) (wire-pod wiki).

Production robots using wire-pod require the “ep” firmware variant — a firmware image that redirects the cloud endpoint to a local server while leaving the rest of the production firmware intact (wire-pod wiki: Things-to-Know; Installation). No cryptographic keys, no bootloader replacement, and no permanent hardware modification are required. Initial setup requires a Bluetooth device on the host machine; wire-pod uses Bluetooth during the pairing and first-run configuration phase (wire-pod wiki: Installation). Once set up, the robot communicates with wire-pod over its ordinary Wi-Fi connection (wevolver; anki.bot) for all ongoing voice traffic.

6.5 The Speech Recognition Layer

Wire-pod presents three speech-to-text engines as interchangeable configuration choices (wire-pod wiki):

Vosk is the default. Vosk is an offline, open-source speech recognition toolkit that runs entirely on the host machine, requiring no API key and no outbound network connection for the recognition step. Vosk models covering multiple languages are available, and its offline-first character means the entire voice path from audio input to text output can remain local (wire-pod wiki).

Coqui is a second open-source offline option. Like Vosk, it operates on the host without a network dependency for recognition, keeping audio data on the local machine (wire-pod wiki).

OpenAI Whisper integrates with OpenAI’s Whisper model. Whisper is available both as a locally-running model and as an API-backed cloud service; wire-pod supports it as the third STT choice (wire-pod wiki). The API-backed path introduces an OpenAI API dependency and associated cost; the locally-run Whisper variant preserves the fully-offline property.

The choice of STT engine is a wire-pod configuration decision — the robot’s firmware and hardware do not change when the STT backend changes (wire-pod wiki). This swappability makes wire-pod adaptable to the host’s resources: a machine too limited for a large Whisper model can use Vosk; a machine with GPU headroom can use a larger Whisper variant for higher recognition accuracy.

6.6 The Intelligence Layer

Beyond transcribing audio to text, wire-pod must resolve the transcribed phrase into an intent and a response. The original DDL cloud handled this through a proprietary knowledge graph and intent-routing layer (Vol 4). Wire-pod supports multiple configurable backends for this function (wire-pod wiki):

Houndify is SoundHound’s conversational AI platform, available as one of wire-pod’s knowledge-graph backends. It provides a broad intent set covering common voice-assistant query classes (wire-pod wiki).

OpenAI (ChatGPT) integration routes queries to the OpenAI API, giving the robot access to a large language model for general question answering (wire-pod wiki). This path requires an OpenAI API key and outbound network access to OpenAI’s endpoints; responses are generative rather than drawn from a fixed knowledge graph.

Together.ai is a third API-backed option, providing access to open-weight language models through Together.ai’s inference infrastructure (wire-pod wiki). Like the OpenAI path, it requires network access and API credentials.

Ollama is the fully-local LLM option. Ollama runs open-weight language models on the host machine without any outbound dependency; pairing Ollama with a local STT backend (Vosk or Coqui) gives a completely air-gapped voice path — audio in, answer out, no third-party service in the loop (wire-pod wiki).

Wire-pod also supports an intent-graph mode for structured intent handling when paired with OpenAI or Together.ai; this mode routes recognised intents through a defined intent graph rather than sending the full query text to an LLM, producing more deterministic behaviour for known intent classes (timers, weather queries, unit conversions) while retaining LLM fallback for out-of-vocabulary phrases (wire-pod wiki: For-Developers-and-Tinkerers).

6.7 The Web Interface

Wire-pod exposes a web interface on port 8080 of the host machine (wire-pod wiki). The web UI provides four functional surfaces:

• Custom intents — operators can define new voice-triggered behaviours, mapping spoken phrases to actions the robot will perform, extending the intent set beyond the defaults (wire-pod wiki).
• Configuration — the active STT backend, the active intelligence backend, robot-specific parameters, and server settings are all managed through the web UI (wire-pod wiki).
• Camera stream — live video from Vector’s front-facing camera streams to the browser through the web interface, providing a remote view from the robot’s perspective (wire-pod wiki).
• Keyboard control — the robot can be driven manually through the web UI’s keyboard control interface, independent of voice commands (wire-pod wiki).

The web interface is the primary operator surface for ongoing wire-pod use. The initial Bluetooth-dependent setup step is a one-time procedure; subsequent configuration, monitoring, and custom-intent authoring are all performed through port 8080 in a browser.

6.8 The Plugin System

Wire-pod provides a Go plugin system that allows third-party extensions to be loaded as compiled .so shared-object files (wire-pod wiki: For-Developers-and-Tinkerers). A plugin can add new intent handlers, new voice commands, or new server-side behaviours without modifying the wire-pod core. The plugin interface is the primary integration point for community-developed capabilities beyond what the wire-pod distribution ships.

The plugin system is documented in the For-Developers-and-Tinkerers wiki section; it is aimed at operators who want to go beyond configuring the existing backends and instead add new first-class behaviours to the server as compiled extensions (wire-pod wiki: For-Developers-and-Tinkerers).

6.9 Platform Support

Wire-pod runs on four platform families (wire-pod wiki: Installation):

• Linux — the primary supported platform; the majority of community installations run on a Linux host, typically a dedicated machine or a single-board computer on the local network.
• macOS — supported.
• Windows 10 and Windows 11 — supported, making wire-pod accessible to operators without a dedicated Linux environment.
• Android — supported, allowing wire-pod to run on an Android device on the local network.

All platforms require a Bluetooth device on the host for the initial setup procedure (wire-pod wiki: Installation). After setup, the robot communicates with wire-pod over Vector’s 2.4 GHz single-band Wi-Fi connection (wevolver; anki.bot); Bluetooth is a setup-only dependency and is not required during normal operation.

6.10 wire-pod and Escape Pod

DDL released its own paid local voice server, called Escape Pod, that served the same functional role as wire-pod: redirecting a Vector’s voice path away from the cloud and to a local server (personalrobots.biz). Escape Pod was a commercial product from the original vendor rather than a community project.

The Escape Pod price was reported at $99 one-time (UNVERIFIED — secondary source only; DDL’s product pages are not reachable). DDL also offered a subscription tier for continued cloud service, reported at approximately $74.99 per year (UNVERIFIED — secondary source), with subscription prices raised around March 2022 (wiki.thedroidyouarelookingfor.info). Wire-pod emerged as the free community equivalent. Given DDL’s operational dormancy and the September 2024 Pennsylvania Attorney General lawsuit over approximately 14,000 unfilled prepaid orders (CBS Pittsburgh), wire-pod is the only reliably obtainable route to a working Vector voice path as of mid-2026: Escape Pod is no longer purchasable through any active DDL channel, and the cloud service it was meant to supplement or replace has been offline since mid-2023 (wiki.thedroidyouarelookingfor.info; iFixit).

The community wiki at thedroidyouarelookingfor.info identifies wire-pod as the community- recommended solution in the current environment (wiki.thedroidyouarelookingfor.info). Community forks and integrations built on wire-pod exist; no named fork was confirmed in any reachable source consulted for this dive — the upstream repository and its wiki are the authoritative references for current capabilities.

6.11 The Component That Makes a Dead-Vendor Robot Fully Alive

The argument made in Vol 1 — that a dead-vendor robot can be kept fully alive through an open community stack — is resolved, technically, in this volume. The hardware was never the problem: the Snapdragon APQ8009, the sensor suite, the navigation stack, the expressive IPS display, and the physical platform all survived the vendor’s collapse intact. The problem was the voice path, and the voice path was a cloud service, not a piece of hardware. Services can be replaced.

Wire-pod is that replacement. It runs on commodity hardware the operator already owns, costs nothing, requires no permanent modification to the robot beyond flashing the ep firmware variant, and provides a voice path functionally equivalent to the original cloud. It adds flexibility the original cloud never offered — swappable STT engines, a choice of intelligence backends from a fixed knowledge graph to a fully local LLM — and it operates without any vendor dependency whatsoever. A Vector running against wire-pod on a local Linux or Windows host hears its wake phrase, understands spoken queries, and responds as it was designed to do. The DDL cloud’s absence is an implementation detail.

The community Python SDK and the ROS 2 wrapper (Vol 7) are the next layer above wire-pod, exposing the robot’s sensors, actuators, and runtime to Python code and, through the ROS 2 path, to the full autonomy stack. Together, wire-pod and the SDK give an unmodified retail Vector a software foundation more programmable and more transparent than anything DDL shipped — the revival is not a downgrade.

Sources

• github.com/kercre123/wire-pod (README) — wire-pod overview: free open-source local server; supported robots (Vector 1.0/2.0 including unmodified production bots); the ep firmware requirement; platform coverage.
• github.com/kercre123/wire-pod (wiki) — STT options (Vosk default, Coqui, OpenAI Whisper); intelligence backends (Houndify, OpenAI/ChatGPT, Together.ai, Ollama); web UI on port 8080 (custom intents, configuration, camera stream, keyboard control); Go plugin system (.so); platform support (Linux, macOS, Windows 10/11, Android); Bluetooth requirement for setup.
• github.com/kercre123/wire-pod/wiki/For-Developers-and-Tinkerers — plugin system; intent- graph mode with OpenAI/Together.ai.
• github.com/kercre123/wire-pod/wiki/Things-to-Know — the “ep” firmware variant for production robots.
• github.com/kercre123/wire-pod/wiki/Installation — platform support; Bluetooth setup requirement.
• github.com/digital-dream-labs/chipper — gRPC/TLS voice backend; ProcessIntent endpoint; MIT license; released as a reference implementation with no built-in STT or NLU; the protocol foundation wire-pod implements. (See Vol 4 for the full account.)
• github.com/digital-dream-labs/vector-cloud — vic-cloud and vic-gateway ARM binaries; the robot-side bridge processes that connect to the chipper interface.
• wiki.thedroidyouarelookingfor.info — community wiki: wire-pod identified as the community- recommended solution; cloud-shutdown timeline (mid-2023); DDL subscription price increase (~March 2022 confirmed).
• iFixit, “Anki Vector” device page — cloud officially offline by January 2024.
• personalrobots.biz/vector-escape-pod-and-open-source-kit — Escape Pod as DDL’s paid local voice server; the commercial context for wire-pod as the free community equivalent.
• CBS News Pittsburgh, “PA Attorney General lawsuit: Digital Dream Labs” — Sept 2024 action; approximately 14,000 unfilled prepaid orders; DDL’s current operational status.
• wevolver, “Vector 2.0 AI Robot Companion” specs — Wi-Fi connectivity (2.4 GHz single-band); the runtime network link over which wire-pod communicates with the robot.
• anki.bot, “Meet Vector” — vendor-side product description (live as Digital Dream Labs).
• Wikipedia, “Anki (American company)” — cloud dependence, corporate timeline.
• Full gated fact base with confirmed/unverified markers and source reachability: 02-inputs/vector_sourcing_notes.md.