Talos Worker: the GPU client that pairs with your account and serves Ollama jobs

What Talos Worker is for, and who should install it

Talos Worker is the downloadable half of the Talos network. You install it on a machine that has a GPU and a local Ollama server, pair that machine to a Talos account with a device code, and from then on the worker accepts inference jobs from the network and runs them against your Ollama models. The README describes the split plainly: the web app never imports the repository, and the two sides only talk over the network, first a device code to pair and then jobs and heartbeats over a WebSocket.

The intended user is someone with idle GPU capacity who already runs Ollama, or is willing to. The requirements section lists Python 3.9 or newer, Ollama running locally with at least one model pulled, and an NVIDIA GPU that is recommended but not mandatory. CPU also works, and nvidia-ml-py is marked optional in pyproject.toml: if it cannot initialise, the worker still runs. That matters because it means the worker is not exclusively a gaming-rig tool. A laptop with Ollama and a small model is a valid target, though the README makes no claim about how much such a machine earns.

The repository also serves a second audience that has nothing to do with sharing a GPU. The README devotes a section to talos-auto, a hosted gateway you can point editors at, with per-tool folders for cursor, vscode, claude-code, jetbrains, zed and aider. If you only want inference inside your editor, you do not need the worker at all. That distinction is worth keeping straight before you install anything.

How pairing and the WebSocket job loop fit together

The mechanism is a three-stage handshake followed by a long-lived connection. First, you obtain a pairing code from the Talos dashboard, under a control the README calls Pair a device. Second, the worker exchanges that code for whatever credential it needs against the server. Third, it opens a WebSocket and stays on it, receiving jobs, running them locally through Ollama, and sending heartbeats that accrue uptime.

The README is explicit that uptime is what accrues while connected, while earnings are credited per served job and shown on the Talos dashboard. Those are two separate meters, and the distinction is the most useful thing in the document. A machine that holds the connection but rarely receives work still records uptime; it does not record earnings. Nothing in the README states a rate for either.

The allocation flag is the other piece of the design worth understanding. The README says --allocation takes a value from 0 to 1 and, in a parenthetical that is easy to skim past, that it maps to concurrency and duty cycle rather than a literal power percentage. So 0.5 does not mean half the GPU's wattage. It means the worker throttles how much work it accepts or how often it runs. Anyone expecting a hardware-level power cap will be surprised.

What the README does not describe is the job payload. There is no schema for what arrives over the socket, no statement about which Ollama models the network will request, and no description of what happens to a job when the local model is missing. The tests/ directory and the talos_worker/ package are where those answers would live, and the README points at neither.

Installing Talos Worker and serving your first job

The install is a single editable pip install from the repository root. The README gives exactly this command, and pyproject.toml defines the console script it produces, talos-worker, mapped to talos_worker.__main__:main.

pip install -e .

Before that will be useful, Ollama needs a model. The README names llama3.1:8b as its example, and the pull is done through Ollama itself rather than through the worker.

ollama pull llama3.1:8b

Pairing comes next. The interactive form prompts for the code you copied from the dashboard, and the README also documents a non-interactive form with both the code and the server URL as flags.

talos-worker pair --code TALOS-XXXX-XXXX --server https://api.usetalos.xyz

The run command takes the allocation value. The README's example is 0.5, and it states that this opens a local dashboard on http://127.0.0.1:8674 with live status and a slider for the same setting.

talos-worker run --allocation 0.5

If you want to confirm the machine is ready before committing to a run, the status command is the one to use. The README says it shows config, GPU and available models and jobs, which is the closest thing to a preflight check the project documents.

talos-worker status

What you should see after run is the local dashboard on port 8674 with a live connection state. What you will not see documented is a log format, a verbosity flag, or a way to run the worker as a background service, so plan on keeping a terminal open or writing your own unit file.

Where the README stops short: earnings, models and failure behaviour

The largest gap is money. The README says you earn a share of real usage revenue and that earnings are credited per served job, but it gives no rate, no minimum payout, no schedule and no worked example. For a client whose whole pitch is sharing a GPU to earn, that is a real omission, and it is the first thing to resolve from the dashboard rather than from the repository.

The second gap is model selection. The worker serves jobs through whatever Ollama has locally, and the README's only guidance is to pull at least one model. It never says whether the network requests a specific model, whether it will pick from whatever you have, or what happens when a job asks for something you never pulled. A mismatch there is the most plausible way for a paired machine to sit connected, accrue uptime, and serve nothing.

The third gap is operational. There is no documented rollback for pairing, no unpair command in the command table, and no statement about how credentials are stored on disk or how to revoke them. The command table lists exactly three entries: pair, run and status. If you need to move a machine to a different account, the README does not tell you how.

Finally, the GPU detection is deliberately soft. pyproject.toml notes that nvidia-ml-py is optional at runtime and that the worker still runs on CPU or non-NVIDIA hardware if it cannot initialise. That is a sensible default, but it also means a misconfigured NVIDIA driver will not stop the worker from starting. It will simply run slower, and you may not notice.

Talos Worker against a self-hosted Ollama endpoint

The obvious alternative is not another worker client but running Ollama yourself and exposing it to whoever needs it. Ollama already serves an HTTP API locally, and the repository's own examples/ directory shows how the hosted Talos gateway is consumed from Go, Node.js, the Vercel AI SDK, LiteLLM and Python. If your goal is to give a few colleagues access to a model on your own hardware, pointing them at your Ollama port is less machinery than joining a network.

The difference in approach is what you get for the extra moving parts. A plain Ollama endpoint gives you direct control over who calls it, which model they get, and how you authenticate them, but it gives you no job queue, no uptime accounting and no revenue share. Talos Worker trades that control for a managed job source and a payout ledger you do not have to build. It also means your GPU is serving requests you did not choose, from users you cannot see, against models the network selects.

A second alternative is to skip the worker entirely and use the hosted gateway from your editor. The README's talos-auto section covers that path, with per-tool config snippets and a verify.sh quickstart in each folder. It solves the opposite problem: consuming inference rather than supplying it. If you arrived at this repository because you want a model in Cursor or Zed, the worker is the wrong half of the project.

Licence, maintenance and the cost of upgrading

The repository carries the MIT licence, which is permissive and places few conditions on reuse. The practical implication for a worker client is that you can read, modify and redistribute the code, including in a commercial setting, provided the licence notice travels with it. That is a statement about the licence text, not legal advice; if you plan to redistribute a modified worker, read LICENSE yourself.

Maintenance is harder to judge. There are no releases retrieved for this repository, and pyproject.toml pins the version at 0.1.0, which is consistent with an early project. The last push was on 2026-07-08. The dependency surface is small, aiohttp and nvidia-ml-py, so the upgrade cost is mostly about the server side: the worker talks to a hosted API over a WebSocket, and the README does not describe a protocol version or a compatibility policy. If the server's job format changes, the client's only defence is the code in talos_worker/.

That is the real cost of adopting this. You are not maintaining a large dependency tree; you are depending on a network protocol that the repository does not version or document. Budget for reading the package source when something stops working, because the README will not tell you what changed.

Editorial conclusion

Adopt Talos Worker if you already run Ollama with a pulled model, you are comfortable with a pip install -e . from source, and you treat the allocation slider as a concurrency knob rather than a power meter. Do not adopt it if you need a documented earnings model, a published job schema, or a Windows-specific setup path; none of those appear in the README or pyproject.toml. Before running it, check that ollama has the model the network expects, confirm the server URL api.usetalos.xyz is the one your dashboard shows, and read talos_worker/ to see what the heartbeat actually sends.

Frequently asked questions

Official sources

1. Issues
2. jmerelnyc/Talos on GitHub
3. License: MIT
4. Project website
5. README