Turning voice traffic into a working transcription service

voxi-clients is a small research repository for unofficial voice and dictation backends that the main voxi application might someday connect to. Its central project, agy-voice, asks a practical question: can audio from a local WAV file be sent through the voice feature already available in the agy command line tool, and can the returned transcript be made available to ordinary applications?

The work began with a cautious experiment. A loopback proxy observed traffic from voice dictation clients while keeping its scope narrow: selected bridge hosts could be inspected, unrelated HTTPS connections passed through as opaque tunnels, and sensitive headers were redacted. WebSocket frames were logged by opcode and size rather than content. The experiment produced a useful negative result for Claude Code: its voice connection did not pass through the configured proxy. The project documents the likely explanation, while clearly labeling it as unconfirmed.

The same technique worked with agy, a native Go program that honored proxy settings. Captured HTTP/2 and gRPC traffic could be decoded into a working picture of the request and response. A schema-free protobuf decoder helped inspect messages before the repository had a protocol definition. The resulting .proto file distinguishes fields confirmed by captured bytes from fields whose names or numbers remain uncertain. That distinction matters when reverse-engineering an undocumented interface: a plausible guess should not quietly become a claimed fact.

On September 16, 2026, issue 001 was closed after the standalone client sent short-abc.wav through the internal BidiGenerateContent RPC and received the transcript “A, B, C.” The client reused agy’s existing OAuth session. This was explicitly accepted as a research risk because the RPC is an undocumented, unstable v1alpha API and the credential was created for agy. The repository describes the client as an MVP, not a supported production integration.

One protocol question shaped the next step. Captures of three separate dictation turns showed that agy opened a new TCP/TLS/HTTP/2 connection each time, completed one gRPC stream, then sent GOAWAY before the next connection. The transcripts were distinct and correct. The server implementation therefore creates a fresh gRPC stream for each transcription request and caches only the OAuth access token, whose lifetime is a separate concern. This is a concrete example of observation preventing a tempting but unsupported design assumption: a bidi streaming RPC did not imply a reusable multi-turn session.

The repository then wrapped that RPC in a local HTTP service compatible with the familiar OpenAI Whisper transcription request shape. Clients send multipart audio to /v1/audio/transcriptions; the server returns JSON or plain text. WAV audio passes through, while other formats use ffmpeg for conversion. A minimal standard-library Go client demonstrates the HTTP interface, and a systemd user unit supports running the service locally. By September 25, commit 2a8ad53 had corrected transcript decoding to follow the observed protobuf fields rather than scanning arbitrary printable bytes. That fix reflects the project’s strongest engineering habit: treat captured wire structure as evidence and decode it deliberately.

This repository shows agentic development as a loop of small probes, explicit uncertainty, and increasingly useful artifacts. The canary tested whether the external mechanism was observable before a full client was attempted. A ticket tracked the MVP to a verified result. Documentation carries risk notes and protocol findings forward so later work can build on them. Harnez conventions are present in the issue tracker, YAML-backed configuration, release guidance, and repository workflow docs. The available commit history does not establish which portions were written by agents or whether parallel agents were used, so this story makes no claim that a single developer could not have produced the code. What it does show is a compact project turning one research question into a proxy, decoder, protocol notes, a command-line client, and a local HTTP service, with claims tied to observations.

Facts