Back to dollama.net

Docs

How the priority system works, what data flows where, and how to configure your tools.

Developer docs

Two kinds of docs, one goal

This page is the concept doc — how priority, privacy, and routing actually work. Already know what you're building and just need the exact endpoint or flag? That's the reference docs.

Concept — you are here

"How does this work?" How dollama's priority queue, privacy model, and routing actually behave, plus how to configure Claude Code to use it. Jump to trust & security, the priority system, privacy details, or configuration below.

Reference — exact specs

"What's the exact endpoint or flag?" Every HTTP/SSE endpoint, parameter, CLI flag, and config key — no prose, just the contract. See the API Reference or the CLI Reference.

Trust & security

Know exactly what you're sharing

Stays on your machine

  • Your files, repos, and working directory
  • Context assembly happens locally
  • Only the inference prompt leaves your machine

Visible in transit (v1)

  • The relay never sees prompt or response content — only routing metadata (which node, timing, token counts)
  • Contributor nodes see the raw prompt
  • Content flows directly between your machine and the matched contributor's machine, in the clear
  • Not yet encrypted end-to-end
  • We don't log prompt content

Use it for

  • Open-source and hobby projects
  • Learning and experimentation
  • Non-sensitive coding tasks

Don't send secrets, credentials, or proprietary code you wouldn't share with a cloud API.

Full privacy details · Source code · End-to-end encryption is on the roadmap, but not in place today
Priority

The more you give, the faster you go

No tokens, no blockchain, no marketplace. Just a running tally that rewards generosity.

Balance model

balance = tokens served − tokens consumed
  • Single queue — ordered by balance bucket plus how long you've waited. Higher balance moves you up; no request waits forever.
  • Idle network — everyone gets instant service regardless of balance.
  • New users — start at zero. Use immediately, but contributors get priority when busy.

Fairness & groups

  • No starvation — wait-time aging means every request reaches the front within a bounded time, no matter your balance.
  • Team pooling — groups share a balance. Run nodes on office machines, everyone benefits.
  • No speculation — balances can't be traded or sold. Coordination, not finance.

Your Hardware First

  • Unmetered — inference on your own node doesn't count against your balance.
  • Preemptive — your requests jump the queue on your own node, always.
  • Zero-cost local — no tokens deducted when your node handles your request.

Network behavior

Idle network Busy network
Response time Instant Queued by balance + wait time
Balance needed? No — everyone served Higher balance = faster, but aging guarantees a turn
New users Full access Lower priority
Privacy

What we see, what we don't

Transparency over marketing. Here's exactly how your data flows through the network today.

What stays on your machine

Your files, repository context, and working directory never leave your machine. The local proxy assembles context locally — only the final inference prompt is sent to the network.

What the relay sees

  • Only routing metadata — which node served the request, timing, token counts
  • The relay never sees prompt or response content — it only matches your request to a contributor node
  • Content flows directly between your machine and the matched contributor node, in the clear — not yet end-to-end encrypted
  • We don't log prompt content
  • Treat it like any cloud API when deciding what to send

What contributor nodes see

Only the raw inference prompt and generated tokens. No file access, no user identity, no conversation history beyond the current request. Nodes are stateless — they process a prompt and move on.

Data Your machine Relay Contributor node
Files & repo context Local only Never sent Never sent
Inference prompt Assembled here Not seen — metadata only Plaintext (v1)
User identity Known Token only Anonymous
Conversation history Full context Per-request only Per-request only

The roadmap: end-to-end encryption

Direct peer connections with end-to-end encryption are on the roadmap, but not in place today. Until then, treat the network like any cloud API: don't send secrets you wouldn't send to a hosted LLM provider.

Configure

Use with Claude Code

1

Launch with one command

Run dollama launch claude — it starts the local proxy, configures the environment, and opens Claude Code automatically. That's it.

tip

Want to contribute too?

Run dollama network first, then dollama launch claude in another terminal — you'll use the network and share your idle compute.

Launch Claude Code 
dollama launch claude
Or configure manually in ~/.claude/settings.json 
{
  "env": {
    "ANTHROPIC_BASE_URL": "http://localhost:11435",
    "ANTHROPIC_API_KEY": "dollama-proxy"
  },
  "model": "network:qwen3.5:9b"
}
Pull the model (contributors) 
ollama pull qwen3.5:9b
FAQ

Common questions

Yes — in v1, contributor nodes see the raw inference prompt in order to generate a response. They don't see your files, identity, or conversation history. Nodes are stateless and process one request at a time. Your files and repo context never leave your machine.
Not yet. In v1, contributor nodes see your raw prompt in plaintext to generate a response (the relay itself never does — it only sees routing metadata). Don't send credentials, secrets, or proprietary code you wouldn't share with a cloud API. Use it for open-source projects, learning, and non-sensitive coding tasks. End-to-end encryption between you and the contributor node is on the roadmap, but not in place today.
Only routing metadata — which node served a request, timing, token counts. The relay is content-free by design: it matches your request to a contributor node, and your prompt and the response then flow directly between your machine and that node, in the clear (not yet end-to-end encrypted). We don't log prompt content, and no data is sold or shared with third parties — see the Privacy section for details.
End-to-end encryption of the direct connection between your machine and the contributor node is on the roadmap — content is already routed directly (not through the relay), but travels in the clear over TLS rather than being end-to-end encrypted. Not in place today. The entire codebase is open source.
It hits the sweet spot: fast enough to run on consumer hardware, capable enough for agentic coding tasks. A single model keeps routing simple. More models may come in future phases.
Ollama installed with qwen3.5:9b pulled. Then run dollama network. The CLI handles registration, heartbeats, and routing automatically. Any machine that can run Ollama can contribute.
Yes. The local proxy exposes an Anthropic Messages API endpoint at localhost:11435. Any tool that supports a custom base URL can use it — Continue, Aider, or your own scripts. See Connect your app for a step-by-step guide (including Raspberry Pi and headless setups).
We like llamas — Ollama is the backbone of this project. But a doe felt right for what we're building: gentle, graceful, and part of a herd. Plus, dollama → doe. It was right there the whole time.