0.38.0 is one addition and two subtractions. The addition is octomind login: your terminal signs in to an Octomind account through the browser, and the key it needs lands on disk without you ever pasting one. The subtractions are two supervisor features we shipped three weeks ago and have now deleted, because when we finally A/B'd them they made the agent measurably worse.
The subtractions are the more interesting half, so I'll get to them properly. But first the thing you'll actually type.
octomind login
Until now, using Octomind's model hub meant a manual round trip: open the panel, create a key, copy it, find the right .env, paste it, hope you didn't commit it. That's four steps too many for something a browser already knows.
$ octomind login
╭ login · octomind account
│ code TX8T-UC7U
│ url https://octomind.run/app/login/cli
│
│ Confirm the code in your browser to finish signing in.
│ waiting…Your browser opens, you confirm the code on a page where you're already signed in, and the terminal finishes on its own.
This is the OAuth 2.0 device authorization grant — the same shape as gh auth login, for the same reason. A CLI is the wrong place to type a password: a terminal that asks for one teaches you to type it into terminals, and a CLI that stores one is a CLI that eventually leaks one. So the CLI never sees a password or a browser session. It holds a device code that is worthless on its own, and the only step that mints anything is a human confirming it while authenticated in the panel.
What lands on your machine is two things:
- A hub key in
~/.local/share/octomind/config/.envasOCTOHUB_API_KEY, mode 0600. Every octomind process already loads that file at startup, so the next command just works. - A panel session in
auth.json— the same short-lived JWT plus refresh token the browser gets, refreshed automatically on a 401. Not a third kind of credential: the CLI is a client of the panel API, and a developer API key remains something you create deliberately when you want to script against the control plane.
The session tokens are minted at the moment the CLI collects them, not when you click confirm, so they're never sitting at rest in a pending-login row.
Keys are per machine
Your laptop and your desktop each get their own key, named octomind-cli-<id> from a stable id the CLI writes once to <config>/machine-id. Signing in on one supersedes only that machine's key. This mattered enough to be the first bug we fixed after the feature worked: without it, logging in on a second machine silently logged the first one out.
Running octomind login again on a machine that already has a working session just tells you who you're signed in as and stops. --force starts a fresh one. What it cannot do is hand your existing key back — only the hash is ever stored, never the plaintext, which is also why a key you lose is a key you replace rather than recover.
/usage
Signing in gets you a second thing worth having: your account's actual numbers, in the terminal.
╭ /usage
│ account you@example.com (pro)
│ spend
│ 4 hours ██████████████████░░░░░░ 74.0% $14.80 / $20.00
│ week █████████░░░░░░░░░░░░░░░ 38.5% $23.10 / $60.00
│ month ████████░░░░░░░░░░░░░░░░ 34.7% $41.60 / $120.00
│ resources
│ balance $9.62
│ storage ███░░░░░░░░░░░░░░░░░░░░░ 11.2% 1.12 / 10 GB
│ network █░░░░░░░░░░░░░░░░░░░░░░░ 2.1% 21.40 / 1000 GB
╰ ✓ /usage · 74% of capThree spend windows against their caps, prepaid balance, and the storage and network you've actually used. Bars go yellow past 70% and red past 90% — that 4-hour window is yellow — because the question /usage answers is "am I about to be cut off", not "what is my exact decimal spend". The footer gives you the tightest window as one number, since that's the one that bites first.
It's registered as a session command, which means it works identically in the interactive CLI, over the WebSocket server, and through the ACP agent — one implementation, every lane.
If you aren't signed in it says so and stops. Octomind works fine against your own provider keys and always will; not being signed in is a normal state, not an error.
One .env for every project
Related and long overdue: octomind now loads a user-scope .env from its config directory before the project-local one. Precedence runs system environment < user-scope < project .env, so you set a provider key once for every project and still override it per repo when a project needs something different. octomind login writes into that file, which is why signing in on Monday works in a repo you clone on Friday.
The two features we deleted
Three weeks ago we shipped two supervisor features that sounded obviously correct. This release removes both. Here's why, because a release note that only lists additions is a release note that's hiding something.
Stale tool result masking. The idea: when the agent reads a file, edits it, then reads it again, the first read is now a lie sitting in context. Mask the stale copy, save the tokens, remove the contradiction. Clean reasoning, real problem.
The A/B — identical binary, identical config, same day — said no. Masking cost $3.39 per solved instance versus $3.07 without it, and burned 2.44M versus 2.06M median tokens on solved instances, for the same 20/30 solve rate. Strictly more expensive for strictly nothing.
The reason is prompt caching. Masking rewrites history at the moving frontier of the conversation, and every rewrite invalidates the cached prefix behind it. The tokens saved by removing a stale file read cost more than they saved in re-sent, uncached context. The feature was reasoning about the wrong resource: context length, when the binding constraint was cache reuse.
Mid-turn plan recitation. The idea: periodically re-inject the plan so a long session doesn't drift from it. In practice it caused early wrap-ups — the agent re-read its checklist mid-flight and started concluding — and it duplicated work octomind already does, since compression injects the plan when it compacts. Two mechanisms fighting for the same job, and the newer one was worse.
Both are gone, along with the config knobs that briefly guarded them. The measured result of removing them is the new baseline: 21/30 solved (70%), $3.28 per solved instance, 1.92M median tokens on solved instances, average judge score 64.2, with no per-instance regression against the reference run. Every headline metric improved by deleting code.
We're stating the A/B numbers rather than just the outcome because the pattern generalises past these two features. Plausible-sounding context engineering can quietly tax you through the cache, and the only way to know is to measure the version without it. Some of what looks like careful context management is just cache invalidation wearing a nice hat.
(Benchmark: SWE-bench-Live lite pilot, 15 instances at k=2, 30 runs, GLM-5.1 with octocode enabled, Docker executor, zero infra-exclusions. Full parameters in bench/baseline.json.)
Also in this release
Empty completions retry instead of failing. Providers occasionally return a completion with nothing in it. That used to surface as a failed run; it now retries at the completion choke point using the existing max_retries budget. This is why the benchmark had zero infra-exclusions — provider flakiness gets recovered inside the binary rather than thrown out of the results afterward.
Throughput in /info. Supervisor stats now track API request duration and report tokens per second, so "this feels slow" becomes a number you can compare across models.
Observe-only tasks stop being told to change things. The verify-gate prompt now classifies tasks that are purely investigative and judges them on whether they answered the question, rather than looking for mutations that were never supposed to happen.
OAuth tokens moved to file-based storage, and the MCP tools and structured-output guides got a pass.
Upgrading
# Homebrew (macOS / Linux)
brew install muvon/tap/octomind
# or from crates.io
cargo install octomindPrebuilt binaries for every platform are on the releases page. Nothing in this release changes existing configuration — the deleted supervisor knobs were only ever defaults, the user-scope .env is additive and loads beneath your project .env, and if you never run octomind login nothing about your provider keys changes.
If you do run it, you'll want an Octomind account — the model hub is open to everyone, and cloud machines are invite-gated while we scale the fleet.
0.37.1 made it harder for the agent to lie to itself about being finished. 0.38.0 makes it harder for us to lie to ourselves about which features earn their keep — and gets you signed in with one command while we're at it.
