Releases

Each task page now has an expandable "Spend by step" section under the cost line. It shows a cumulative spend chart over time, a hover tooltip with model and cost details, and a full step-by-step table with input/output tokens and per-step cost. Engine-run dollars are shown as a separate caption — only step-level usage is charted.

Two new MCP tools let you check migration drift and apply pending migrations without opening the web UI. `migrations_status` reports whether the build's migration journal matches the live database. `migrations_apply` runs every pending bundled migration, with the same advisory lock, backwards-journal guard, and audit event as the web UI's Apply button. Available to any authenticated MCP client.

The workspace now warns you the moment a merged migration hasn't been applied to the live database, so schema changes can't quietly fall out of step with the running app anymore. A banner appears when migrations are pending and links to a detail view where you can read the exact SQL that's about to run. From there you can apply it in one click — safe to press even if a deploy or a second click lands at the same time, and every attempt is recorded with who ran it and what happened. Prefer to run it yourself? The page hands you the exact command to copy. The banner clears itself once the database catches up, however the migration got applied.

Any in-progress, in-review, or blocked task can now be copied into a local coding session, not just ones paused for budget. From there, the same connection lets you read the task, leave comments, answer approval prompts, and move the task forward — all without opening the web app. Copy the pickup prompt shown on the task page, or connect a local session via Settings → API keys.

The Costs dashboard used to show model spend only. It now also surfaces spend from automatic PR-review sessions, GitHub Actions CI minutes for each pull request, and sandbox compute cost (once a per-minute rate is configured for a repo). Find PR-review spend in its own section on the Costs page, and CI/sandbox figures on each task's page.

The task detail page now shows a quiet hint next to the Rotate button when the active agent session was created with an earlier build than the one currently deployed. Rotate to pick up the latest agent changes. The hint stays hidden when the session is already up to date or the build information can't be fetched.

API keys can now be rolled — the system mints a replacement key while the old one keeps working for a chosen grace period (1h, 24h, 3d, or 7d), so services using the old key don't break mid-rotation. The "now" option disables the old key immediately, with a two-step confirm to prevent accidents. The replacement key is shown once, using the existing reveal-and-copy panel. Find it under Settings → API Keys: click **Roll** on any key, then pick a grace period.

When a task runs up against its budget, the factory now generates a handoff prompt you can copy into your local coding agent. The prompt includes the task's spec, any pushed work, budget context, and closing instructions — so you can keep it moving without losing context. It shows up on budget-paused task pages — look for "Copy local pickup prompt."

Task pages and the Costs dashboard now show which model (or models) handled the work, right alongside the cost. The Costs page also breaks down total spend by model, so you can see where the money is going at a glance. Older tasks from before this tracking started simply show cost as usual, with no model listed.

The task detail page now shows the current working branch in the metadata caption, with a direct link to the branch tree on GitHub. When a pull request exists the PR head branch is displayed; otherwise the latest recorded run branch is shown. One click and you're on the code.

The factory now picks the best model for each task's complexity. Lightweight, well-specified work runs on a faster model; cross-cutting or complex work gets the most capable one; most tasks stay on the standard model. When creating a task, you can see the tier in the advanced options or override it yourself. Every task page shows its active tier, and repo configs can customize which model each tier maps to. Tier changes take effect on the next turn — the running session finishes on the model it started with, then the factory rotates to a fresh one.

You can now generate a personal API key and use it to connect tools like Claude Code straight to your tasks, releases, and diary — no more copy-pasting through the UI. Keys are shown once when created and can be revoked anytime. Find them under your account menu → API keys.

Repo operators can configure a per-task dollar budget in the repo settings. When a task's accumulated model spend crosses the configured threshold, the system pauses further work with a comment on the thread — a user resumes from the task page as usual. The task page's cost display shows current spend alongside the budget for at-a-glance comparison.

New `/costs` dashboard shows total known spend, split by engine runs vs. session calls, with per-task breakdowns. Build and Dogfood stat tiles display cost per completed task. Full task list is filterable by kind and sorted by cost. Designs use lightness-only proportion bars and no new color hues — pastels remain reserved for status indicators.

The task page header displays a summary line whenever a task incurs model costs: "Model spend $0.66 · 3 runs · 41k in / 9k out tokens." Dollar figures come from `claude-code` engine runs; token counts come from the eve agent's own model steps. Zero-cost tasks show nothing.

The agent now keeps a running diary of lessons, missteps, and ideas it notices while working, so they aren't lost once a task ends. Find it under Diary in the top nav — newest first, filterable by category.

When you create a task, you no longer have to pick whether it's a build or a dogfood task — leave it alone and the agent classifies it for you, with its reasoning posted to the thread. The picker still exists if you want to set it yourself; find it under an "Advanced" toggle on the task form. If your pick doesn't match what the task actually asks for, the agent will flag the mismatch and ask before starting work instead of running the wrong flow.