dothething (DTT): a local shell agent that plans, browses, and edits files
an autonomous AI agent: you describe the thing, it does the thing.
At a glance
- What is it?
- Dothething is a BSD-3-Clause shell script that installs a Python agent into /tmp/dothething and drives it against OpenRouter models. It is aimed at people who want unattended task execution on their own machine, and its main cost is a first run that provisions SearXNG, Notte, and a virtualenv before anything happens.
- Who is it for?
- Adopt dothething if you want unattended, browser-heavy research or extraction tasks on macOS or Linux and you are comfortable letting a script provision a Python venv, SearXNG, and Notte on first run. Do not adopt it if you need a stable long-lived install path, a minimal dependency footprint, or reproducible runs across machines, since the README places the runtime in /tmp/dothething.
- Can I use it commercially?
- Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The task-shaped gap dothething is trying to fill
Most command-line AI tools assume the unit of work is a file. You point them at a repository, they edit code, you review a diff. dothething assumes the unit of work is a sentence. The README opens with the claim that you give it a task, walk away, and come back to results, and the examples back that up: finding the ten largest public companies by revenue that went bankrupt in the last twenty years and writing a markdown report, or researching the ten largest data breaches of 2025 and summarising causes. Neither of those has an obvious repository to sit in.
The intended user is someone doing research, extraction, or browser-driven chores rather than refactoring. The tool description lists research, data extraction, browser automation, file editing, and code execution. That is a wide surface, and the breadth is the point: the agent decides which of those it needs. If your work is already well served by an editor-integrated assistant, dothething is solving a problem you do not have.
Model roles, the oracle, and how a run actually progresses
dothething is not one model. It assigns models to four roles: main, worker, oracle, and browser. Normal mode uses DeepSeek Flash for the agent, Gemini Flash for the worker, Claude Sonnet for the browser, and GPT-5.6 Terra for the oracle, all at xhigh reasoning. Advanced mode swaps in Claude Fable plus an Astra oracle at max reasoning. Quick mode one-shots on Claude Opus Fast with a trimmed toolset.
The worker exists to farm out grunt work to a cheaper model. The oracle is asked for a second opinion when the agent is stuck. That split is the most interesting design decision in the project, because it means a long run is not billed at a single rate. The README states that token usage and dollar cost are tracked via OpenRouter, with Anthropic prompt caching for cost reduction, and --max-cost USD stops and checkpoints when cumulative cost reaches a threshold.
Quick mode changes the loop shape rather than just the model. According to the README, its first reply stacks every tool call the job needs, staged with exec_order where order matters, and the next reply is the answer. The loop cap drops to 15 turns, and skills stay out of the prompt until invoked. That is a materially different execution model from the plan-and-track loop used elsewhere, and it is why the README frames quick mode as for a fast answer, not a research project.
Search and browsing: SearXNG, Notte, Camoufox, and source weighting
Web access is not a single HTTP call. The README describes a local SearXNG instance for search, with general-web engines fetching through a real browser so that Google and similar engines answer instead of serving a bot wall. Primary-source APIs (OpenAlex, Crossref, PubMed, arXiv) are queried directly and weighted above general web hits. That weighting is a real editorial choice: for a literature or citation task it should push results toward indexed sources rather than whatever ranks well.
Page interaction runs through Notte and Camoufox, described as a Firefox fork built to avoid fingerprinting. The stated capabilities are content extraction, captcha solving, and multi-step interactions. Captcha solving is optional and depends on a 2Captcha key, which the first run prompts for. Browser sessions can be reused across runs with --browser-session NAME, and the default is a separate session per thread, or default in MCP mode. --headed and --headless control whether the window is visible.
The honest reading here is that dothething is betting on evasion as a first-class feature. That is a legitimate engineering response to bot walls, but it also means the browser layer is the part most likely to break when a target site changes its defences. Nothing in the supplied material describes how failures in that layer are detected or retried.
Getting it running, and what the first run actually provisions
The documented install is a one-liner:
curl -fsSL dotheth.ing/dtt.sh | bash -s -- --install
That places the script in ~/.local/bin/dtt and adds the directory to PATH if it is not already there. The README notes macOS has it by default and most Linux distributions do not. Cloning works too: git clone https://github.com/fluffypony/dothething.git && ./dtt.sh --install, and ./dtt.sh runs without installing at all.
First run prompts for an OpenRouter API key, which is required, and a 2Captcha key, which is optional, saving them to ~/.dtt/env with mode 0600. Exporting OPENROUTER_API_KEY in the shell skips the prompt, and shell environment values take precedence over the saved file. The README says the first run also takes a couple of minutes to set up a Python venv, install SearXNG, and set up the Notte browser framework, and that everything else installs into /tmp/dothething.
Configuration lives in a few predictable places. MCP servers are wired through ~/.dtt/mcp.json. Custom skills load from ~/.dtt/skills/<skill-name>/SKILL.md following the Claude Code convention, and only names and descriptions sit in context until a task matches and the full instructions are pulled in. The README also claims the agent manages its own configuration: tell it to add an API key or install a skill and it handles the file edits and reloads itself. Requirements are macOS or Linux, Python 3.11+, and wl-clipboard or xclip for clipboard and image support on Linux.
Where dothething gets in your way
The install location is the first problem. The README states that everything else is installed automatically into /tmp/dothething on first run. On many Linux distributions /tmp is cleared on reboot, and on all of them it is a directory with weak isolation guarantees. A tool that provisions a Python venv and a browser framework there is not built for a machine you leave running for months. The README does not say whether this path is configurable or whether state survives a reboot, so treat it as a question to answer before you depend on the tool.
The second issue is cost variance. A run can spawn a main agent, a worker, an oracle, and a browser model, and the README gives no token or dollar estimates for any of the example prompts. --max-cost gives you a ceiling in USD, which is the right control to have, but a ceiling is not a budget forecast. Anyone running advanced mode on a long task should expect the bill to be shaped by how often the oracle is consulted, and the README does not describe what triggers that.
The third is the mid-task input model. Pressing any key while the agent works lets you type instructions, and Ctrl-Q queues input for after the current step finishes. That is a thoughtful touch for interactive use, and it is also a reason the tool is a poor fit for genuinely unattended cron-style execution, where nobody is present to steer a confused agent. For that pattern, the --pipe flag with its documented exit codes (0 complete, 2 partial, 1 failed) is the relevant interface, and it is worth noting the project ships a partial-success code rather than pretending tasks always finish cleanly.
How it differs from a terminal coding agent
The closest comparison in the same shape is a terminal coding agent such as Aider. Aider assumes a git repository and a chat about the code in it; its core loop is proposing edits, applying them to files, and committing. dothething assumes a task description and a toolbelt, and file editing is one capability among several alongside browsing, search, email, and clipboard access.
The practical difference shows up in two places. First, provenance: dothething weights primary-source APIs above general web results and routes general search through a browser, which matters when the output is a report rather than a patch. Aider has no equivalent concern because the source of truth is your working tree. Second, verification: a coding agent's output is checkable by running tests. A dothething report on bankruptcies or data breaches is not. The agent tracking its own plan and progress, as the README describes, is not the same as an external check on whether the findings are right. If your task has a test suite, the coding agent wins on verifiability. If your task has no repository at all, dothething is addressing something Aider was never designed for.
Licence, maintenance, and the cost of staying current
dothething is BSD-3-Clause, which permits commercial and closed-source use and requires retaining the copyright notice and licence text. That is a permissive licence, and it means the practical constraint on adoption is not legal but operational. Keep the licence file with any redistribution and you have met the stated terms. This is not legal advice; check the full text in the repository if you plan to redistribute.
The repository is not archived and the last push recorded is 2026-09-07. No releases were retrieved, so there is no tagged version to pin against. That matters more than usual here because the documented install path is a curl pipe from dotheth.ing/dtt.sh rather than a package manager, and the runtime provisions itself into /tmp on first run. The upgrade story is effectively re-run the installer and let it rebuild. There is no changelog in the supplied material and no version number to compare against, so you cannot tell from the outside whether a given run picked up a change.
The dependency surface is also part of the maintenance bill: a Python venv, SearXNG, the Notte browser framework, and Camoufox, plus optional 2Captcha and AgentMail accounts. Each of those can break independently of dothething itself. Anyone pinning this for a team should mirror the install script rather than curling it live, and should decide in advance what happens when the browser layer stops working against a site you depend on.
Editorial conclusion
Adopt dothething if you want unattended, browser-heavy research or extraction tasks on macOS or Linux and you are comfortable letting a script provision a Python venv, SearXNG, and Notte on first run. Do not adopt it if you need a stable long-lived install path, a minimal dependency footprint, or reproducible runs across machines, since the README places the runtime in /tmp/dothething. Before committing, verify three things on your own hardware: that the first-run provisioning completes behind your proxy or firewall, that ~/.dtt/env is written with mode 0600 as documented, and that --max-cost and --max-loops actually halt a runaway task the way the flag table says they do.
Community notes