roger is a token market where the GPU owner and the model user never meet, and the broker signs for both

The node dials out to the broker, so there is no port to open on your machine

The networking decision is the one that makes this work on a home connection. A provider node does not accept inbound traffic. It dials out to the broker and long-polls it for jobs, which means there is no inbound port to forward and no tunnel dependency. Behind any NAT, one command starts the process:

roger share                                    # auto-detects your local model, starts earning
# options: --price-in/--price-out, --free-window 03:00-03:30, --schedule '<time-of-use JSON>',
#          --confidential (TEE-attested), --upstream <your OpenAI endpoint>

The flow in one line runs client, broker, node, local model: the CLI discovers and uses, the broker matches, meters and co-signs, the node dials out and then serves and signs. The broker lives at broker.rogerai.fm and is the only public component in the picture. What comes back the other way is a local OpenAI-compatible endpoint at `http://127.0.0.1:4141/v1` with an API key attached, so any tool that speaks that API can be pointed at it without knowing a marketplace exists.

Every response carries a receipt signed by the provider and counter-signed by the broker

This is the part that separates roger from a generic relay. Each token carries a model-lineage record, described as a receipt signed by the provider and counter-signed by the broker, tracing the response back to the model that produced it. The receipts are hash-chained and dual-signed, and the mechanism lives in `internal/protocol`. The chain matters because it makes the record append-only: a receipt cannot be swapped after the fact without breaking the link to the next one, and two signatures mean neither side can produce one alone. Two things are deliberately left out. The broker is content-blind, storing token counts and signed receipts and never prompts, so it can meter and settle a transaction without ever holding the text that was exchanged. And identity is pseudonymized to providers, so the person consuming tokens is not the person being billed. The receipt SDK is separately licensed, which is what lets you verify what you were charged without asking the operator.

A 24 hour price lock, a free window and a schedule decide what a provider earns

Pricing is per token, and a provider sets the rate on both directions with `--price-in` and `--price-out`. Two things sit on top of that. The first is a 24 hour price lock, so a quoted rate does not move under a request that is already in flight, and consumers can rely on the number they were shown. The second is a free window, written as `--free-window 03:00-03:30`, which marks a stretch of hours where requests cost nothing, and a broader `--schedule` that takes a time-of-use JSON document for several such stretches. This is the mechanism that lets someone with an idle gaming machine serve a model at off-peak hours and charge properly during the working day. On the buying side, the same subcommands line up with wallet operations: `roger balance` shows credits and `roger topup 10` buys them through Stripe. A confidential tier, marked with a TEE attestation, lets a provider take work that the plain tier would decline.

Compatibility is decided by the served API, not by the trainer, quantizer or vendor

The auto-detection list is deliberately about servers rather than models. Ollama, llama.cpp, LM Studio, Unsloth Studio, vLLM, Osaurus, Jan and LiteLLM are recognised directly, and the project says so explicitly: compatibility is determined by the served API, not the trainer, optimizer, quantizer, model format, or vendor. A model trained or quantized with Unsloth works as long as something compatible serves it. A second group, including LocalAI, TGI, SGLang, KoboldCpp and text-generation-webui, is reachable through `--upstream`, with `--upstream-key` when the endpoint needs one. That phrasing also pre-empts the wrong conclusion: the named integrations make discovery easier, and they are not a vendor allowlist. The exact upstream contract lives in `docs/hosting-compatibility.md`, along with a list of current gaps, which is the document to read before assuming a host will be picked up.

The broker stores token counts and signed receipts, and never your prompts

Content blindness is the property that lets one component sit between strangers. The broker keeps token counts and signed receipts and never prompts, and it still meters, matches, co-signs and relays, exposing an OpenAI-compatible API whose specification is served at `/openapi.yaml` and also lives in the repository as `cmd/rogerai-broker/openapi.yaml` in OpenAPI 3.1 form. Because the specification is public, the broker is not a moat: `BROKER-SPEC.md` is written as an open spec that anyone can self-host or federate, and `web/` holds the front end that talks to it. The deployment picture follows from that. The container image is described as the only deployed component and is a tiny static binary built with `CGO_ENABLED=0` on a distroless base, running as a nonroot user, with the broker binding `0.0.0.0:$PORT` because the hosting platform injects the port. Broker configuration is short: a database URL, a port, a fee, seed credit settings, moderation model settings, and an optional Redis URL for a shared-state cache.

Two licences sit side by side, and only the protocol half is open

The split is deliberate and it is stated in the project rather than buried. The node-agent protocol and the usage-receipt SDK are Apache-2.0, with the reasoning given plainly: an interoperability surface only counts as open if it is actually open, so anyone can implement a compatible node, or verify what they were charged, without asking. Everything else is PolyForm Perimeter 1.0.0, which is source-available and free for any non-competing use. The grant is specific: you can self-host your own broker for your own community, and you cannot run it as a competing commercial marketplace service. `LICENSING.md` has the exact file list. The practical consequence is that the parts you need in order to trust your own bill are open, while the part that would let a rival marketplace exist is not. GitHub itself detects no standard licence for the repository as a whole, which is consistent with a dual-licence file set rather than a single identifier.

The Makefile carries a warning about the Go linker silently ignoring a bad symbol

One comment in the build file is worth reading twice, because it describes a failure that produces no error. Version stamping works by passing `-X main.Version=...` at link time, and the comment notes that the Go linker silently ignores `-X` for a symbol that does not exist. `roger-tower` declares its version as a lowercase `version` in package main rather than the client's `Version`, so reusing the client's flag would have looked correct in the recipe, exited zero, and shipped a binary still reporting `dev`. Two separate flag variables exist purely to keep those two symbols apart, and the comment ties them to the flags in `.goreleaser.yaml`, which is what actually stamps the binaries an operator downloads. The build target compiles five things: the broker, the client, a tokenizer sidecar, the tower and a local tower variant, then creates `bin/rogerai` as a symbolic link to `bin/roger` so the legacy command name keeps working.

The image builds on a newer Go than the module asks for, on purpose

The module path is `rogerai.fm/roger/v6` and it declares `go 1.25.0`, while the container is built `FROM golang:1.26`. That gap is deliberate rather than drift, because both the image and the Makefile pin `GOTOOLCHAIN=local`, which disables the automatic toolchain download the Go command performs by default. With downloading off, the builder has to already satisfy the declared language version, so the image carries a buffer instead of relying on a fetch. The broker build is a single static compile with `-trimpath`, and the result is copied into a distroless static Debian 12 image as a nonroot user with port 8080 exposed. Broker seed settings deserve a look before you deploy it, because they decide how much free credit the platform owes. New users get `ROGERAI_SEED_CREDITS=100` until the Stripe wallet lands, and only the first `ROGERAI_SEED_LIMIT=1000` distinct wallets ever receive it, tracked in a `seed_counter` row in Postgres and bumped atomically with each grant so concurrent runs cannot over-grant. A limit of zero or less disables the cap entirely.

Editorial conclusion

Use roger if you have a spare GPU and an open model you are happy to serve, or if you want an OpenAI-compatible endpoint without running the model yourself and you do not mind paying a broker's take rate. Do not expect the whole thing to be open source in the usual sense: only the node protocol and the receipt SDK are Apache-2.0, and the marketplace itself is PolyForm Perimeter. Before you commit, read LICENSING.md to see which side of the line your use falls on, confirm your host serves the OpenAI-compatible API listed in the hosting compatibility document, and check the price lock window and the free window defaults against what you would charge.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes