Talos worker: a device code, a local Ollama, and a duty cycle called allocation

The repository is Talos, the package is talos-worker, and the text says it belongs in another repo

Three names are in play for one project. The repository is jmerelnyc/Talos. The distribution in pyproject.toml is talos-worker, with packages set to talos_worker alone and a single console script talos-worker bound to talos_worker.__main__:main. And the opening paragraph states that this is the downloadable client, intended to live in its own public GitHub repo, talos-worker. In other words the document describes a repository that does not match the one you are reading, and the packaging metadata already carries the intended name. That also explains the split in the audience section: sharing a GPU is this client, while the editor side is a different concern with its own folders. Another line settles the relationship to the hosted service, saying the Talos web app never imports this repo and that the two only talk over the network, a device code to pair and then jobs and heartbeats over a WebSocket.

`talos setup <tool>` is documented, but no `talos` entry point is registered

The editor half of the documentation tells you to install the sdk folder and run `talos setup <tool>`, which is claimed to write the real config file for you and back up the original. No such command exists in this package. The scripts table in the build metadata declares exactly one console entry point, talos-worker, and there is no `talos` binary among the dependencies or elsewhere in the tree. So either the command lives in a different distribution, or it is planned, or the documentation drifted. The same drift shows in the manual route, which points at six per-tool folders, cursor, vscode for Continue and Cline, claude-code, jetbrains, zed and aider, each with a guide, a config snippet, a verify.sh quickstart script and a bundled SDK example. All of those are documentation assets, and none of them is importable from an installed talos-worker.

Two declared dependencies, and Ollama is not one of them

The dependency list is short: aiohttp at 3.9 or newer, and nvidia-ml-py at 12.535.0 or newer. The second carries a comment saying it exists for NVIDIA GPU detection and is optional at runtime, since the worker still runs on CPU or on non-NVIDIA hardware if it cannot initialise. Everything else the worker needs to do its actual job sits outside the package. Ollama has to be running locally with at least one model pulled, and the example given is `ollama pull llama3.1:8b`. Nothing in the metadata mentions Ollama, no client library for it appears in the dependency list, and no error is described for the case where the local Ollama is missing or has no models. So the failure modes of the one component the whole design depends on are undocumented, while the optional component, GPU detection, is the one that gets a comment.

Allocation is a duty cycle, not a power limit, and the status page binds to localhost

The run command takes one documented option:

talos-worker run --allocation 0.5

The value runs from 0 to 1 and sets how much of the machine you offer, with an explicit warning that it maps to concurrency and duty cycle rather than a literal power percentage. That distinction matters for anyone hoping to cap electricity use or GPU load: the mechanism is how often and how many jobs run at once, not a wattage ceiling. Running it also opens a local dashboard at http://127.0.0.1:8674 with live status and the allocation slider. Binding to the loopback address is the one security decision stated in the text, since the dashboard can move your allocation and it is not reachable from the network. Uptime accrues while the client is connected, and earnings are credited per served job and shown on the Talos dashboard.

The pairing code and the server URL appear in exactly one command

Pairing has an interactive and a scripted form:

talos-worker pair            # prompts for the code
# or non-interactively:
talos-worker pair --code TALOS-XXXX-XXXX --server https://api.usetalos.xyz

The interactive form asks for a code you get from the dashboard under Pair a device, and the non-interactive form takes both the code and the server address explicitly. That second line is the only place a server URL appears anywhere in the documentation, and the run command shows no `--server` option of its own, so the endpoint has to be remembered from pairing time or found through the status output. The status command is described as showing config, GPU and available models and jobs, which makes it the place to confirm that pairing stuck. The three commands in the table, pair, run and status, are the entire command surface; there is no documented way to unpair, no daemon mode and no service unit.

The only documented install is editable, and the repository publishes no releases

Installation is one line:

pip install -e .

There is no wheel, no published package name to install from an index, and no pinned version to ask for. The project version is 0.1.0, which matches a first release rather than a shipped series, and the repository has no GitHub releases at all, so there is nothing to pin to even if you wanted to. The last push to the repository is dated 2026-07-08. A tests directory exists at the root, but the build metadata declares no test extras and no test command, and there is no linting or type checking configuration either, so the quality gates that produced this code are not visible from the packaging side. The license is MIT in both the repository record and a LICENSE file at the root, which is the one piece of metadata here that agrees with itself.

Editor SDK folders, docs and examples are all outside the packaged distribution

The root listing is mostly documentation. Alongside .gitignore, CONTRIBUTING.md, LICENSE, README.md and pyproject.toml sit aider, claude-code, cursor, docs, examples, jetbrains, sdk, talos_worker, tests, vscode and zed. Of those, only talos_worker is packaged, because packages is set to a single-element list. The examples tree goes deeper with a README and folders for go, litellm, node, python and vercel-ai-sdk, which is a spread that says more about who the other audience is than the worker code does: Go, Node.js, Vercel AI SDK, LiteLLM and Python stacks all have a slot. The consequence for the worker is simple. An editable install gives you a client and nothing else, and everything a newcomer reads first lives in directories that never reach site-packages. Anyone documenting a setup for a colleague should therefore point at the repository rather than at pip.

Jobs arrive from the network, and no per-job confirmation is described

The work itself is inbound. The client pairs, connects, and then serves open-model inference jobs that the network sends it, forwarding them to a model pulled in your local Ollama. Earnings are credited per served job, so the incentive to accept work is built into the design. What the visible documentation does not describe is any gate in front of an individual job: no per-job approval, no allow list of prompt sources, no record of what was served beyond uptime counters, and no statement about whether prompts or responses leave the machine. There is also no documented way to see a job history, only config, GPU, available models and jobs from the status command. That gap is not a reason to skip the project, but it is the thing to settle with the operator before you leave an allocation above zero on a machine you care about.

Editorial conclusion

This is for people who already have a spare NVIDIA box with Ollama installed and are willing to serve other people's prompts from it. Read the trust surface first: the client accepts jobs pushed to it over a WebSocket and forwards them to a model running on your machine, and the visible documentation describes no per-job gate, so treat the allocation slider as the only control you have and start it low. Check that the `talos-worker` command is what you want rather than the `talos setup` path in the same README, since only the former is registered in the package metadata. Note that the only documented install is editable, that Ollama is a requirement that never appears in the dependencies, and that version 0.1.0 with no published releases, plus a last push dated 2026-07-08, means you are running a client whose interface may still move.

Frequently asked questions

Official sources

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