Doingly · Code mode

Describe the work. Not the model.

Doingly Code is one command line for developers who would rather stay in the work than shop for a model. The secure CLI runs agent work on your machine today; next comes a task-aware router that decides how much model capacity each task deserves — behind the same command, so choosing a model stops interrupting the work.

Built today: a private-alpha CLI that runs Goose locally with safe permission defaults.
Building next: automatic task-aware routing that right-sizes model capacity behind the same command.

Request private-alpha access See where routing goes

$ doingly run "add retry logic to the payment webhook"

agent goose · Agent Client Protocol

endpoint Doingly Gateway

writes denied by default · pass --yes to allow this run once

$ doingly doctor

✓ config valid · credentials in system keyring, not in config

✓ agent goose runtime found (ACP)

· network not checked — offline by default. Run doingly doctor --probe for one explicit, bounded check.

A representative alpha session. The CLI runs Goose — a separate, Apache-2.0 agent runtime — locally on your machine; it is not a fork.

In the alpha today

The CLI foundation is built

Before a router can be trusted to hand your task to the right specialist, the ground under it has to be boring: local execution, honest credential handling, and permissions that default to no.

Interface: An interactive terminal, or one shot and done. Work in a session, or fire a single task with doingly run "…". Setup is doingly configure; health is doingly doctor.
Runtime: Goose runs locally, over ACP. The CLI is a small, inspectable client for Goose — a separate Apache-2.0 agent runtime — and drives it on your machine through the Agent Client Protocol. It is not a Goose fork.
Endpoint: Doingly Gateway, or bring your own. Point the CLI at our Gateway or at any custom OpenAI-compatible endpoint you already trust.
Credentials: Keys never land in generated config. They live in your system keyring; when no keyring is available, the CLI says so plainly and uses a 0600-permission file instead.
Permissions: One-shot runs default to no. Permission requests are denied unless you pass --yes — and that grants allow-once for the run, not standing authority.
Diagnostics: Offline unless you say otherwise. doingly doctor checks your setup without touching the network. Probing the endpoint is an explicit, bounded choice: doingly doctor --probe.

Truth boundary: this is a private alpha — a Python CLI at v0.1, on Linux ARM64 first. There is no public download, full-screen TUI, auto-updater, account system, remote sync, or cloud deployment yet, and we won't pretend otherwise.

Next layer · planned direction

Automatic task-aware routing is the next layer

Dashed means planned. Nothing in this section ships in the current alpha. It is the direction the CLI foundation was built to carry.

“You wouldn’t ask a brain surgeon to sort the mail.”

Frontier models are the surgeons: brilliant, deliberate, expensive. Most of a working day is mail. Right now developers do the sorting by hand — picking a model per task, every task, all day. That sorting is exactly the job the router takes.

One CLI. No model roulette.

Planned · not in the alpha

Manual model picker · the status quo

Anthropic exposes a model family — Haiku, Sonnet, Opus — while other providers add tiers of their own. The choosing still lands on you. Every pick is a small decision you absorb, and every re-pick is a break in developer flow.

Doingly Auto · planned routing mode

Doingly Auto is a planned routing mode, not a proprietary model name. Behind the same Doingly command, its routing policy would send routine work to efficient open models, keep ordinary coding on capable general models, and escalate hard or stalled work to frontier reasoning. The value is the decision layer — not another label to memorize.

The model can change. Your command does not.

1 · You say

The task, in plain words.

doingly run "fix the flaky auth test"

No model name. No provider tab-hopping. The request is the whole interface.

2 · The router weighs

What this task actually needs.

It reads only what you hand it — never silently scanning your code — and right-sizes model capacity for the job. A policy decision, not magic and not keyword matching.

3 · Work lands in

The right capacity lane.

Openefficient open models for routine work — renames, boilerplate, mechanical edits

Generalcapable general models for ordinary coding — the flaky test lands here

Frontierfrontier reasoning for architecture, gnarly debugging, review

And it can escalate: when signs of progress stall or a task turns out deeper than it looked, the router re-routes the work up to frontier reasoning — a judgment from the signals above, not magic.

Planned direction, stated plainly: the routing flow above is not in the published alpha. No routing accuracy, benchmark, or cost-savings claim is being made, and the router is designed around the task you describe — not around access to your private code.

Fewer model menus.

Stop relitigating “which model?” before every task. Describe the work once; the routing decision stops being your job.

Less provider switching.

Frontier capacity stays on the problems that deserve it and routine work uses right-sized capacity — without you hopping between providers and tiers to make it so.

Fewer workflow interruptions.

Escalation happens behind the interface. When a task needs more capacity the router reaches for it, and you stay in the work instead of re-picking a model mid-thought.

Private alpha

Bring us your day of tasks.

Request private-alpha access to the CLI and show us where model selection gets in the way. The workflows you bring will help shape the routing layer we build next.

Schedule a 20-min call Private alpha · Python CLI v0.1 · Linux ARM64 first · no public download yet