dogear
A coding agent that runs on your own machine, with a workspace you can watch, and a receipt for every run.
dogear talks to a local model through Ollama, gives it the tools a coding agent needs (read, write, edit, search, shell, tests, git, a real browser), and shows you what it does while it does it: files being typed, diffs, the terminal, and a live browser that you and the agent share. Nothing leaves your machine unless the agent opens a web page, or you choose a remote model for a project (see Remote models).
What it does
- Claude Code style tools.
Read, Write, Edit, MultiEdit, Glob, Grep, LS, Bash (with background processes), RunTests, Git, Outline, FindSymbol, WebSearch, WebFetch, TodoWrite, Task (sub-agent), AskUser (multiple-choice forms) and more. Names and shapes follow the Claude Code conventions, so models that learned them use them well.
- A browser you both control. Headless Chrome with its own profile, driven over the DevTools protocol by a small built-in client. The agent navigates, reads the page as element refs, clicks and types; you watch the screencast in the UI and can take over at any time. CAPTCHAs and logins are never bypassed: the agent hands over to you.
- One status block per turn. Working (with the current step and a Stop button), Waiting for you (the permission question or the model's form, right there), Checking the result, Done or Stopped. The steps underneath stay folded; the answer is rendered once and never re-laid out.
- The receipt. When a run ends, the harness reports what it knows itself: the tests it saw run, the page it measured (before and after the fix pass), console errors it caught, and a status it computed, not the model: Verified, Unverified, Stopped.
- Flows: show, don't tell. Press Record in the browser panel, do the thing on the page, name it. The steps (clicks, typing, navigation, with locators that survive a reload) are saved in the project; the agent replays them with
browser_flow ("do this for the other twenty products"), and a flow marked as a check runs after every change to web files and shows up on the receipt.
- Live workspace, on demand. Open it when the status block offers something to look at ("Open index.html", "Watch the browser"); nothing opens on its own. New files are typed in line by line, edits are shown as diffs, shell output streams into the Output panel, a preview server serves the project on a separate origin.
- Three modes, named by what they ask. Ask all (every edit and command), Ask commands (edits run, commands ask), Don't ask.
- Plan first. A toggle on the composer: the model investigates with read-only tools and proposes a task board. You edit, approve or reject it. Then the harness hands the model one task per turn; the model closes each task with a one-line summary or asks for a new plan when something does not fit. Every task runs in a fresh, small context (request, board, changed files, the task itself), is logged on the plan card with its context size, the task strip above the chat shows where the run is, and the self-check and quality gate run once, after the last task.
- Undo. Every run starts with a shadow checkpoint of the project (a git commit under
refs/dogear/..., never touching your branches). One click puts the files back.
- Edit and retry. Hover a message, edit it and send it again as a new session based on this one; compare the two side by side, keep the files of the one you like. Parallel variants (two to four sessions in their own git worktrees) can be switched on in the settings.
- Quality gate for web work. After changes to HTML/CSS/JS the harness measures the page itself (overflow, contrast, holes in grids, empty boxes, tiny targets, placeholder images, generated-UI tells) at desktop and phone width and starts a fix pass when it finds something. Optionally a copy check proofreads the visible text against the brief.
- A look before the page. For a web brief planned with Plan first, the approval card shows pictures of 25 looks, one solved page per art style in a library of 300 design plans: linocut, blueprint, risograph, terminal, ukiyo-e, … Pick one (its technique, palette logic and type go into every task briefing, applied to your subject), say "surprise me", or none. The audit measures defects; this is the cheap way to get taste.
Quick start
You need Python 3.12+, uv, Ollama with at least one tool-capable model, and Chrome or Chromium for the browser features.
ollama pull qwen3.6:35b-a3b # the default model; any tool-capable model works
git clone https://github.com/gedachtgemacht/dogear
cd dogear
uv run python -m dogear --open # http://127.0.0.1:7870
./start.sh does the same. uv run python -m dogear --help lists the options (--port, --root, --reload).
Point the project field in the header at a directory, pick a mode, describe a task. Type / in the composer for commands (/plan, /compact, /remember, /init …). Shift+Tab cycles the mode, Esc stops a run.
To start dogear at login and get a launcher in the application menu (Linux with systemd):
scripts/install-desktop.sh # scripts/install-desktop.sh --remove undoes it
Models
dogear works with every Ollama model that supports tool calls. On a laptop with 30 GB of shared memory the defaults are:
| Role | Model | Why |
|---|
| main | qwen3.6:35b-a3b | 7/7 on the benchmark at ~70 tokens/s |
| helper (titles, suggestions, fast sub-agents) | qwen3.5:4b | small and quick; chosen automatically as the smallest installed tool model |
| embeddings (design library) | qwen3-embedding:0.6b | optional; without it the library falls back to keyword search |
여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗
