Dulus: an agent runtime that drives Gemini, Claude and GPT through their own web sessions

The key-procurement problem Dulus is built around

Most agent frameworks assume you already have credentials. You sign up, you paste an API key, you add a card, and the framework starts working. Dulus inverts that order. The README states that on a fresh machine, pip install dulus followed by dulus is the whole setup, and that Dulus boots straight into Gemini with no API key and no account. The mechanism it names is a headless browser: Dulus opens Gemini, captures the anonymous web session, and talks to the model through that session rather than through an official API endpoint. That is the specific problem being solved. Not agent orchestration in the abstract, but the friction between installing a tool and having a working model behind it. The intended audience is closer to a solo developer or a hobbyist on a fresh Linux box than to a platform team with an existing provider contract. The README also lists LiteLLM for 100+ providers, local models via Ollama, and a /lang command covering 34 languages, so the no-key path is a default rather than the only path.

What the browser-session mechanism implies about reliability

Capturing an anonymous web session is a different engineering bet from calling an API. An API has a versioned contract and a documented error surface. A web session has a DOM, a login flow, and whatever the provider changes on a Tuesday. The README does not describe how Dulus detects a session that has expired, what it does when the anonymous path is closed off, or whether it falls back to a configured key automatically. Those are the questions that decide whether the no-key default is a convenience or a recurring interruption. The same caveat applies to the Claude and GPT paths, which the README says Dulus also reaches through their own web sessions. Nothing in the supplied material describes a retry policy or a session-refresh command, so treat that as unverified rather than as handled. The trade-off is explicit even if the README does not frame it that way: you get zero setup cost in exchange for depending on a surface that was not designed to be driven programmatically.

Install, key minting, and the /fuel QR flow

The install path is short. pip install -U dulus, then run dulus to enter a REPL. The README gives two in-REPL commands for authentication: /login dulus signs in through OAuth with a browser window, and /login dulus key mints a dulus_sk_* key that is shown once. After that, the README points any OpenAI-compatible client at the hosted router by exporting OPENAI_API_KEY with the minted key and OPENAI_BASE_URL set to https://control.dulus.ai/v1. The second flow is the token one. /fuel prints a balance and a scannable reload-wallet QR, and /fuel deposit prints the QR alone. The README says you scan with Phantom or Solflare, send $DULUS, and Fuel credits land on the account. The README also claims the key-minting path has been in the pip package for a long time, which is a claim about the package rather than about the website. Note what is not documented here: there is no stated minimum deposit, no confirmation latency, and no description of what happens to in-flight agent runs when Fuel hits zero.

Four surfaces and a command map that the README never prints

Dulus describes itself as one engine with four surfaces: GUI, web, CLI, and Telegram. The README links to a command map section but the supplied text does not include the command table, so the only commands I can confirm are /login dulus, /login dulus key, /fuel, /fuel deposit, and /lang. If you are evaluating Dulus for a Telegram deployment, you will need the actual repository to learn how the bot is configured, whether it shares the same session store as the CLI, and what the token is stored in. The README also mentions a Mesa Redonda feature and 2,000 MCP servers with 100K skills, but without the command map or configuration keys those numbers are marketing surface, not something you can plan around. The honest read is that the documentation is uneven: the install and fuel flows are spelled out with copy-pasteable commands, while the multi-surface story is asserted and left to the repository.

Release naming is the biggest adoption risk

The release list is the part I would look at hardest before committing. The most recent entries are priv6.0.7, tagged Dulus 6.0.7 binaries (maintained repo), dated 2026-09-07; then v3.13.6 on 2026-09-01; then v3.12.1 on 2026-08-29. The README opens with an alert that v6.0.8 is out and that you should use the binaries, linking to a separate repository, Dulus-Ai/dulus-updates. So the version numbers do not form a single line, and the current feature set lives somewhere other than the repository you are reading. For a Python package on PyPI, that is a real operational question: which artifact does pip install -U dulus give you, and does it match the binaries? The README does not answer it. If you pin a version and build tooling against it, you may be pinning the older line while the actively developed one moves in a different repository. That is a maintenance cost you should price in before the first commit, not after.

Licence and the hosted-service boundary

Dulus is GPL-3.0. That matters more than usual here because the project has two halves with different characters. The runtime is GPL-3.0 Python you install locally. The hosted router at control.dulus.ai and the $DULUS token are a service, not code you receive under the same terms. If you embed the runtime in something you distribute, GPL-3.0 obligations attach to that distribution, and the README does not discuss the boundary between the two halves. I am not giving legal advice; the point is that the licence question is answerable only by reading the LICENSE file and, if you plan to ship, by someone qualified to read it with you. The README does not state whether the hosted router has separate terms, and the supplied material does not include a link to them.

Where a plain OpenAI-compatible client is the better choice

The obvious alternative is not another agent framework. It is the boring option: an OpenAI-compatible client pointed at a provider you pay directly, with the model access handled by a key you control. The difference in approach is the whole point. Dulus reaches models by driving their web interfaces and, for the hosted path, by routing through control.dulus.ai with a dulus_sk_* key. A direct client reaches models through a published API with rate limits, error codes, and a deprecation policy. If your agent runs unattended, if you need reproducible failures, or if a compliance reviewer will ask where the prompt went, the direct client wins on every axis except setup cost and price. Dulus wins on setup cost and on the no-key default, and the $DULUS path is aimed at people who would rather hold a transferable credit than a subscription. Those are different buyers. Pick the one that matches how the agent will actually be operated, not the one with the shorter install.

Editorial conclusion

Dulus fits engineers who want a local agent loop with Gemini as the default brain and no key procurement step, and who are comfortable reading Python when the browser-session path misbehaves. It does not fit anyone who needs a stable, documented contract for model access or a clean upgrade story, because the README points to a separate binaries repository for current features and names priv6.0.7, v3.13.6 and v3.12.1 as the most recent releases. Before adopting, verify three things: whether the pip package and the binaries repository are the same codebase, what the anonymous Gemini session actually permits, and whether the GPL-3.0 obligations are compatible with how you plan to distribute anything built on it.

Official sources

1. KevRojo/Dulus on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases