Capabilities

Output

{"text", "language", "words", "duration_s"}. Each entry in words carries word, start, and end in seconds — enough to build subtitles, seek to a phrase, or align a transcript against the source audio.

{
  "text": "the quick brown fox",
  "language": "en",
  "duration_s": 3.0,
  "words": [
    { "word": "the",   "start": 0.00, "end": 0.20 },
    { "word": "quick", "start": 0.20, "end": 0.55 }
  ]
}

Word-level probability is part of the schema but the backend does not populate it in practice, so treat it as absent rather than as a confidence score.

Getting better transcripts

Use --initial-prompt when the recording contains names or jargon. It biases the decoder toward words it would otherwise guess wrong:

dollama transcribe standup.wav \
  --initial-prompt "dollama, Ollama, Qwen, relay, OET, Fly.io, Neon"

Pass --language when you know it. Auto-detection costs accuracy on short or noisy clips. Use --verbatim only when hesitations matter — for meeting notes or captions, leave it off so fillers are dropped.

Output

{"model", "dims", "embeddings", "usage"}. embeddings is one float array per input text, in the same order as the inputs, and dims is the vector width.

{
  "model": "qwen3-embedding:0.6b",
  "dims": 1024,
  "embeddings": [[0.0123, -0.0456, "…"]],
  "usage": { "prompt_tokens": 8 }
}

Batch rather than loop. Sending N texts in one call is one network round trip and one backend call; sending them one at a time is N of each. A single request accepts up to 512 texts or 8 MiB of text, whichever comes first.

The network supports a single embedding model rather than a hot-swappable set. Vectors from different models are not comparable, so one model network-wide is what makes an index built today still searchable tomorrow — and it keeps a small embedding model resident alongside a node's LLM role instead of thrashing them against each other.

Speech-to-text: your own machines by default

Three separate questions apply here. Where does the work run? By default, dollama transcribe sends your audio only to machines on your own account. It does not use group members' machines, and if none of yours is available the request fails instead of going elsewhere. Pass --public to also allow public volunteers' machines. Whose requests does a machine serve? Only machines running in Open Network mode (dollama network) serve speech-to-text and embeddings, so one of your machines must be running that mode, even if it is the machine you are typing on. Who can read the audio? The serving machine, and the relay while the audio passes through it.

The relay enforces the own-machines rule twice: when it picks a machine, and again when that machine claims the request.

Embeddings and your mode

In CLI v0.72.0 and earlier, dollama embed always uses the Open Network, whatever mode the app is in. A fix that makes it follow your chosen mode (dollama private / group / network) is merged and will ship in the next release. Until then, do not use dollama embed for sensitive material. See Privacy Policy §12.

What the relay holds

Audio clips travel as a content reference the serving node pulls over the reverse content tunnel; the relay passes the audio along in memory and does not store it. Embedding inputs ride inline with the request for latency reasons, so they sit in the relay's cache like any other request: minutes, then they expire. No content is written to the relay's database or logs. The relay can read what passes through it. Each hop is encrypted in transit (TLS), but requests are not yet encrypted from your machine to the serving machine, so the relay can read them. See the Privacy Policy for the retention table and Docs for the full data-flow picture.