2026.08LatestAugust 2026
Know what your dbt work costs
Cost Insights turns your warehouse's own usage history into what each scheduled job, run, model, environment, and developer actually cost, in Snowflake credits, BigQuery TiB or slot hours, or Databricks DBUs, with two numbers finance always asks for: what failed runs cost and what state-aware runs saved. Around it, the organization grows up: signed webhooks with a full delivery history, AI providers you choose and validate centrally, settings for dbt 2.0 adoption and assistant registration, one Access URLs card for every outside tool, and BI tools reading published metrics as plain SQL tables. Every run keeps the dbt warnings it printed, grouped and trended over 30 runs and shown on the pull request that introduced them, the editor stops a run that would build the wrong branch and offers a sandbox that follows yours, commits pushed from dbdeux show Verified on GitHub, and the catalog lists the warehouse tables and views dbt never built. GitHub projects can connect through the dbdeux GitHub App, so teams whose organization blocks personal tokens get full branch, commit, run, and pull request workflows with access their GitHub administrator grants to one repository. Search anything from one box on every page: files, lines of SQL, models, columns, warehouse tables, jobs, runs, people, and settings, each result carrying its current state and the actions you would take next, with Atlas one key away when what you typed is a question. A failed run explains itself: the Failure summary separates the one or two root causes from everything they took down, classifies each in plain words with the warehouse message and what to do about it, and opens the editor on the model that carries the error, while Source pre-flight catches a missing upstream table before anything is built and retries rerun only what failed, only when a retry can help. dbt 2.0 arrives alongside dbt Core, with a one-click readiness check on every environment that shows exactly what the new engine would raise before you switch a single run, plus SQL lint and format built into the editor and every pull request. State-aware runs prove which models would produce the same result as last time and skip exactly those, with a reuse rate, an estimated saving, and a recorded reason for every rebuild. And your projects are now open to the AI assistants your team already uses: Claude, Cursor, or any MCP client can read your models, runs, and governed metrics, and run approved dbt commands, inside permissions you approve one by one and can revoke at any time. Alongside them, semantic definitions get a proper editor with a no-YAML Builder, and generated documentation becomes a versioned history you can browse, compare, and share as a link that stays still.
Cost InsightsOrganizationsWebhooksVersion ControlSearchJob Schedulingdbt 2.0SQL QualityAI AssistantsState-Aware RunsNotificationsAtlas CatalogSemantic LayerSnowflakeLanguages
New
- Repository access through the dbdeux GitHub App. A GitHub project can reach its repository through an installation your GitHub administrator approves for that one repository, with no personal access token to create, share, or rotate. The administrator needs no dbdeux account: install, pick the repository, send the installation id. Check access confirms it covers the repository and can read and write it before anything is saved.
- One access method per project, never a silent fallback. Choose a personal access token, the dbdeux GitHub App, or public read-only access when you create the project and change it any time in Version control settings. Branches, commits, editor runs, scheduled jobs, and Slimmer CI builds all use exactly that method, and if an installation is later suspended or narrowed, the project names the reason and links to the GitHub page that fixes it, with Re-check installation to carry on.
- Cost Insights. A new organization tab reads your warehouse's own usage history through a connection you pick and attributes every query to the dbdeux job, run, model, environment, and developer behind it, without writing anything to the warehouse. Three lenses (Usage, Query time, Builds), breakdowns by job, environment, developer, warehouse, category, or model, a share-of-warehouse figure, and a status card that always says plainly whether the numbers are current, estimated, or waiting on a price.
- The two cost numbers finance asks for. Saved by dbdeux State shows the warehouse usage that state-aware runs avoided, grounded in what the skipped models cost when they last built, and Spent on failed runs shows what was consumed before a scheduled run failed or timed out.
- Cost in your warehouse's own currency: Snowflake credits at your contracted rate, BigQuery TiB billed or slot hours for on-demand and capacity pricing, and Databricks DBUs at list price. Redshift is named as not supported yet rather than given an invented per-query figure.
- Organization webhooks. Post signed run and notification events to your own systems in three steps (endpoint, events, job or environment filters), with a signing secret shown once and rotatable, Test endpoint, a delivery history that keeps every payload and every response, one-click Redeliver, and a webhook that pauses itself with the reason after ten straight failures so nothing fails silently.
- AI providers for the whole organization. Choose Anthropic, OpenAI, Google Gemini, or Azure OpenAI, let dbdeux supply the credential or bring your own, validate each one before anyone depends on it, set the default provider and model, decide whether members' personal keys may be used as a fallback, and switch every AI feature on or off with one control.
- Organization Settings: reuse dbt's parser state between deployment runs by default for a faster start on large projects (each environment can still override it), decide whether any member or only owners and admins may move an environment or job to dbt 2.0, and let AI assistants register themselves for members to approve.
- One Access URLs card with every address an outside tool asks for: public API, API reference, Semantic Layer query and GraphQL, MCP server, metrics-only MCP, and BI tools, each with Copy and a plain-language note on what it is for and how it signs in.
- BI tools read metrics as tables. Tableau, DBeaver, notebooks, and other SQL tools connect to a project's published semantic catalog over Arrow Flight SQL with a service account token, see one table per semantic model, and write ordinary SELECT statements that dbdeux turns into governed metric queries, so the dashboard number is the Atlas number.
- Warnings that do not scroll away. Every run and every pull request build keeps the dbt warnings it printed, with a count on the run, a Warnings tab grouped by code and category, Open in editor on the exact line, a 30-run trend on the job marking each group New, Increased, Steady, Decreased, or Resolved, and a downloadable report. Report only: run status and PR checks are never affected.
- This run will not use your branch. When an environment builds from a branch other than the one in your editor, the run pauses with a plain explanation, names the branch-only models that would not be found, and offers a one-click switch to a sandbox that follows your branch, or Run on the pinned branch anyway.
- Signed commits, no key to look after. Turn on Signed commits in User Preferences, click Create signing key, paste the public key into GitHub, and every commit dbdeux pushes shows Verified. Pause, replace, or delete the key at any time; commits already pushed keep their signature, and the commit toast reports the outcome of every push.
- Warehouse tables and views in the Atlas Catalog. Objects dbt never built now appear alongside models with columns, types, and row counts from the last connection scan, clearly typed and filterable, honest about partial scans and connections you cannot see, and findable from Search anything.
- Show Beta features, per person. A switch in User Preferences reveals features still being polished, marked with a Beta badge; turning it off hides them again without losing anything you created.
- Every run explains its own start. Startup diagnostics stream into the live Output ahead of the first dbt line, scheduled runs show a per-step timeline with status, exact command, start, and duration, and failure notifications name the project, environment, step, and command.
- Search anything, from anywhere. Ctrl or Cmd + K opens one search box on every page that finds files, models, columns, warehouse tables, scheduled jobs, runs, environments, connections, people, and settings, grouped by kind, with a typo-tolerant match marked as close and prefixes such as col:, @owner, #tag, and > for commands when you want to narrow down.
- Search inside your code, not just names. sql: and code: find every line in your SQL and YAML, and in the compiled SQL of the last build, show the matching line, and open the editor at exactly that line, or the compiled version read-only, so "which models still use this macro" is answered in seconds.
- Results you can act on. Each search result carries its live state, last run and duration, freshness, owner, whether it changed on your branch, frozen for maintenance, and the actions you would take next: Show in DAG, Preview, Run, Test, Compiled SQL, Lineage, Run now, Failure summary, or an environment's Variables, Validate, and Test tabs. And when your query reads like a question or the results are thin, Ask Atlas is the last row, one Enter away with the same words.
- A failed run explains itself. The new Failure summary tab on every run separates root causes from the models and tests they took down, classifies each cause in plain language (Upstream object missing, Permission denied, Timeout, SQL error, and more) with the warehouse message and what to do about it, and offers Open in editor on the node that carries the error.
- Source pre-flight for scheduled jobs. Before the first dbt step, the run checks that every upstream table it reads exists and is readable, with its own credentials, and either stops at once with the list (Fail fast) or leaves out only the affected models and runs the rest (Skip descendants). Every run keeps a Sources tab with the result, and the owners of an unavailable source are notified with the table named.
- Retries that know when to try. An automatic retry now reruns only the failed and skipped nodes of the failed step, keeps everything that passed, and only fires when every root cause is one a retry can fix, so a late table is retried and a permission error is not.
- dbt 2.0 is here, alongside dbt Core 1.8 and 1.10. Pick the next-generation engine for one run, one scheduled job, or as an environment default, on Snowflake, BigQuery, Databricks, Redshift, and MotherDuck, with PostgreSQL and Microsoft Fabric available as experimental. The picker only offers 2.0 where the warehouse supports it.
- Know you are ready before you switch. Every environment has a one-click dbt 2.0 readiness check that parses your project on the new engine without building or changing anything, lists every issue 2.0 would raise grouped by file with Open in editor on each line, marks warnings as informational, and keeps a history so you can watch a project go from findings to Ready.
- Two dbt 2.0 run options for runs, jobs, and PR builds: Continue on error keeps downstream models building past a failed parent so one bad night surfaces every real failure at once, and Skip redundant tests drops tests dbt can already prove pass, for shorter builds with the same coverage.
- SQL lint and format in the editor. Lint the current file, every open SQL file, or the whole project against your team's SQLFluff rules, see findings as line markers and in the Problems tab, and click Format to apply every fix the rules know, only to saved files and never over edits in progress.
- Two optional, report-only tabs on every pull request build: SQL lint findings for the files the PR changed and a dbt 2.0 readiness report for the project at that PR, both grouped by file with Open in editor. Neither changes the PR result or your Git provider check.
- dbt 2.0 user-defined functions in the Atlas Catalog: each function shows its signature, arguments with defaults, return type, every overload with where it is defined, and its source, and appears in Browse and search alongside models and macros.
- A Notifications hub for the whole organization. Connect the dbdeux Slack app once and pick channels from a list, then add routing rules for the alerts a single run cannot tell you about: a job still failing after the number of runs you choose, the recovery that follows, a schedule that never started, a run taking far longer than usual, a downstream refresh that did not go through, maintenance mode, catalog change requests, and account and plan events. Each rule delivers to any mix of Slack, Microsoft Teams, PagerDuty, email, a signed webhook, and the new in-app bell.
- Quiet alerts, not blind ones. Every routing rule can carry a cooldown and quiet hours; repeats and off-hours events are recorded as skipped with their reason in an organization-wide delivery history you can filter by status, event, job, environment, channel, and date. PagerDuty resolves always go through.
- One daily digest on top of immediate alerts, at the time and time zone you choose, to Slack, Teams, or email, with Send now for the mornings you want it early. And a personal Notify me on Slack card where each member can opt into direct messages when their job fails, a request lands on their desk, or a model they own changes, with a test DM to confirm the match. Tick several events at once to create matching rules in one pass, and watch your routing-rule allowance on the card itself.
- Owners of a catalog object now hear about it. A new catalog version that changes a model you own, a pull request build that fails on it, or a question asked about it reaches its Business and Technical owners by email and Slack, with exactly what changed. Each person chooses which of the three they want in User Preferences.
- Ask the owners directly from the object. Every catalog entry has Ask a question and Request a change from the owners, and the resulting thread lives on the object with replies and an Open, In progress, Resolved, or Declined status, so the answer becomes documentation instead of a chat message that scrolls away.
- Snowflake connections speak your identity provider's language. External OAuth signs in to Snowflake as an application registered in Entra ID or Okta, works everywhere a key pair does (scheduled jobs, pull request builds, the Semantic Layer, AI assistants), and can be switched off centrally without touching Snowflake or dbdeux. The connection drawer carries the full setup guide.
- On a developer sandbox, each developer connects to Snowflake as themselves. Snowflake OAuth gives every person their own sign-in, with connected-as and expiry shown on the connection, a 90-day session with one-click reauthorize, and privileged roles kept out by design.
- Job run history has a long memory. Finished runs stay in recent history for at least 90 days (longer on higher plans), then move to a read-only archive where every run still opens from its link, with its log, so the recent view stays quick and the record stays complete.
- Notify on test warnings. A test marked severity: warn gets its own notification gate, so a stale feed or a soft quality rule reaches the team while the run keeps going and the build stays green.
- Invite people who have never used dbdeux straight from Organizations > Members: type an email, pick a role, and they receive a link to set their password. The membership becomes active with exactly that role the moment they first sign in, so a pending invitation is a promise rather than access. Nobody can invite above their own role, invitations expire and can be resent or revoked, and every one stays on record with its delivery status and an audit entry.
- Name a future teammate as a catalog owner before they have an account. Type their email into the owner picker and they are invited and pencilled in as owner in one step, shown as an invited chip until their first sign-in turns it into a real owner. The person who actually knows the model can be its owner on day one.
- Every catalog object can now name its owners, and they are two different people: a Business owner for what it means and a Technical owner for who fixes it. Owners are real organization members picked from a search, adopted in one click from the ownership hints already in your dbt meta, groups, and exposures, or assigned to a whole selection at once from Browse. Names appear on share links, contact details never do.
- Ownership rules for large projects: give every object in a folder, a modeling layer, or a dbt tag a default owner and the rule re-applies on every new catalog version, so a model added next week is owned the moment it lands. Inherited owners are labelled with the rule that assigned them, hand picks always win, and a rule you delete takes back only what it assigned.
- Ownership coverage joins documentation and test coverage: an ownership ring with a business and technical split, a per-layer breakdown, an Unowned list you can bulk-assign or cover with a rule in one step, and a clear count of objects whose only owners have left the organization, so succession happens before an incident rather than during one.
- AI assistants can now work with your projects directly. Connect Claude, Cursor, or any MCP client from the new MCP Server tab and it can explore your models and lineage, read how last night's run went, ask a governed metric, and run approved dbt commands, instead of guessing at table names it has never seen.
- Sign in to connect, and the assistant acts as you: it sees what you can see and is refused what you would be refused. A consent screen lists every permission it asked for, and you tick the ones you are willing to grant. Anything you left unticked does not appear in its tool list at all.
- Read-only SQL, on your terms: with your approval an assistant can run a single read-only query as you, with your connection access rules, a row cap, and a timeout. It is available only to signed-in connections, never to a shared token, so warehouse data is never reachable by an unattended credential.
- Your connected assistants, in one list: what you authorized, what it may do, when it was last used, and a Revoke that ends its access immediately. Every assistant action is attributed in the audit log, by your name for a sign-in and by the token name for a service account.
- Assistants answer metric questions from your published semantic definitions rather than writing their own SQL, so the number an assistant gives back is the number your dashboard gives back, and the question lands in query history labelled as coming from an assistant.
- Maintenance mode for jobs: pause a whole workspace's schedule in one action with a reason your teammates see and a duration that ends it automatically. Scheduled and chained runs are recorded as Skipped rather than quietly missing, in-flight runs are never cancelled, every job shows as Frozen, and an owner can still force one urgent run with a recorded override.
- State-aware runs: stop paying to rebuild models that have not changed. Before a scheduled run executes, dbdeux fingerprints every model from its compiled SQL, its configuration, its parents, and your warehouse's own freshness metadata, then skips only what it can prove is identical to the last successful run. Anything unprovable rebuilds, so a state-aware run is never less correct than a full one.
- Clone restore instead of rebuild: a model whose fingerprint matches but whose table is missing from this environment is restored by clone rather than recomputed. Zero-copy on Snowflake and BigQuery, deep clone on Databricks, which makes standing up a fresh staging environment minutes of metadata work instead of hours of compute.
- State-aware runs now cover nine warehouses. Snowflake, BigQuery, and Databricks report when data last changed, so any model can be proven unchanged. Redshift, PostgreSQL, MotherDuck, Microsoft Fabric, Azure Synapse, and Athena prove reuse for models built from seeds and other models, and rebuild anything fed by a source rather than skipping it on an assumption. Every other warehouse runs exactly as it would have.
- Warehouse capability on the State tab: instead of a table you have to find yourself in, the tab reads the warehouse the environment is connected to and says in one line what reuse can do there, so expectations are set before the first run rather than inferred from a disappointing reuse rate.
- State analytics per environment: reuse by day, node outcomes, reuse rate, estimated time saved, and top models by savings over a 7, 30, or 90 day window, so the value is a number rather than a claim.
- Why models rebuilt: every rebuild records its reason in plain language, from "Model changed since the last run" to "SQL produces different results each run" and "Cannot tell if source data changed", each with an explanation of what it means and what to do about it. Reuse being lower than you expected is now a question with an answer.
- Choose your engine: DbDeux State runs natively against your own warehouse with nothing to buy and no metadata leaving your account, or opt in to dbt Labs' hosted dbt State if you already have it. Analytics keep each engine's history separately so you can compare them on your own project.
- Post-run actions can fire on success with data changes, so a dashboard refresh or a notification happens on the nights that produced new data and stays quiet on the nights that did not.
- Semantic model editor: one definition, three ways to work on it. A form Builder for datasets, relationships, metrics, and hierarchies with no YAML required, a full YAML editor with completion and inline validation, and Edit with Atlas, where a sentence becomes a diff you review before anything is written. Your comments and untouched fields are preserved either way.
- Definition history and restore: browse the commits that touched a semantic file, view any earlier version, and restore it as a reviewable working change. Save validates first, and publishing stays a separate, deliberate step.
- Catalog versions and history: every documentation generation publishes a version instead of overwriting the last one. Filter by environment, browse any earlier version with a banner telling you which one you are reading, and compare two versions to see exactly which models, columns, types, descriptions, and tests moved.
- Share links pinned to a version: pin a documentation link to an exact published version so a data contract, board pack, or audit response keeps showing the same thing after your team regenerates docs. A version an active link points to is always kept.
- Atlas file and folder attachments: pin the files or whole folders you want considered, see them as removable chips, and keep them attached across turns. Attachments are read at send time, so Atlas sees your uncommitted edits.
- Measures in the Semantic Layer: the raw numeric fields metrics aggregate over are now first-class, so it is clear where a number comes from, and every metric can be read as either a business definition or the exact compiled query.
- Snowflake programmatic access tokens: connect an MFA-enforced Snowflake account without disabling a security control or setting up keys. The token keeps the role restriction and expiry you gave it.
- Clone a job: copy a working job, adjust the copy, and resume it when it is ready. Clones start paused so a copied schedule cannot fire while you are still editing it.
- Every Slack message and email now carries a View run in dbdeux button that opens the right workspace, the right job, and that exact run's log in one click, however old the run is. Job pages keep their address, so a run link pasted into a ticket lands a teammate on the same run.
- Post-run action outcomes on every run: a timestamped log of what fired, what was skipped and why, and what failed with the response it got back. "The dashboard did not refresh" is now answerable from the run itself.
- Generate docs on run: tick one box on a scheduled job and your documentation refreshes after every successful build, publishing a new catalog version each time. Documentation stops being something someone has to remember, and a docs hiccup never turns a successful run into a failure.
- Semantic query history: every metric query the project runs is recorded, whether it came from the catalog, a saved query, GraphQL, or an AI agent, with the metrics and grouping asked for, the SQL generated, the timing, the row count, and the catalog version it was answered from. Failed attempts are kept with their error, which is the half most tools throw away, and any entry can be replayed with one click.
- GraphQL access to the Semantic Layer: tools and front ends that already speak GraphQL can discover metrics and dimensions, list saved queries, and run a metric query in a single request, pinned to the branch and published version they choose.
- dbdeux now speaks your language. Pick English, French, German, Spanish, Portuguese (Brazil), Hindi, Bengali, Russian, or Arabic under Language in your preferences and the interface changes immediately. Each language is listed in its own name, Arabic lays the interface out right to left, and the choice is yours alone rather than something set for the whole team. Your models, columns, and descriptions stay exactly as your team wrote them.
- Your first visit already speaks your language: dbdeux honors your browser's preferred language before you choose anything, and the first time it does, a notice in that language offers Keep or Use English so the automatic choice is always a visible one. The guided tour gained a Language step so new teammates learn where the setting lives in their first minutes.
Refined
- Come back to a tab you left open this morning and it picks up where you were: an idle session signs itself back in quietly, keeps the workspace you had selected, and every part of the app, from the editor to a running job's live log, carries on without a sign-in screen or a stale error in the way.
- Each job has an Activity tab: every edit and every run in one timeline with the person or API token behind it, and one click opens the full Audit Log pinned to that job and its runs. Runs started through the API are labelled as such in the runs list.
- Job statistics follow the window you care about: Today, Yesterday, and the last 7, 31, 60, or 90 days, with success rate, duration, and the runs list all recomputed for the range you pick.
- Existing Snowflake password connections show a switch-by date and a Deprecated auth pill on the Databases list, and switching to Key Pair or a Programmatic Access Token changes only the credential: account, user, warehouse, database, schema, and role are kept. New Snowflake connections start on a key, a token, or OAuth.
- A link opened while signed out takes you to that page after sign-in, whether it points at a run, a catalog object, or a Semantic Layer definition, so a shared address lands where it was meant to.
- The metric catalog leads with business names and keeps the technical name underneath, browses one file at a time or all at once, explains each section in plain language, and remembers how wide you like the rail.
- Runs and Jobs are far easier to search: filter runs by environment or environment type, search across job, tag, project, environment, and person in one box, and find jobs grouped by the environment they target. Run now reports its real state as it happens rather than leaving you guessing.
- Warehouse re-scan in the editor: the refresh control now separates redrawing what is already known from going back to the warehouse for objects that did not exist at the last scan, so a missing table is never a mystery. Snowflake scans are substantially faster.
- Re-scan a single schema instead of a whole connection, so picking up one new table on a warehouse with hundreds of schemas takes seconds. If a scan is already running, dbdeux says so rather than stacking another on top of it.
- Post-run actions guide you to Integrations when you have no credential set up yet, so the path from an empty list to a working refresh is one click, and a job summarizes its refresh targets with a tooltip naming every workspace and model.
- Projects hosted by dbdeux work the same everywhere: connection tests and scheduled runs use the project files directly, with no Git branch to resolve and no wording implying you need a repository.
- Creating a project now shows the workspace it will be created in, and lets you change it in place. The setup checklist ticks items off live as you complete them.
- Copy results the way you meant to: an explicit right-click menu for cell, row, column, selection, or the whole table, with or without headers, plus CSV, JSON, Markdown, and SQL INSERT so results paste cleanly into a spreadsheet, a ticket, a pull request comment, or a seed file with no reformatting.
- Power BI targets are picked by name from the workspaces your credential can see, rather than looked up elsewhere and pasted in as identifiers, and selected targets read back as names.
- Testing a connection you are editing now uses the values on the form, so a changed account or role is verified before you save. Blank secret fields keep the stored secret, and the test saves nothing.
- The Semantic Layer names the branch it is reading, and follows the branch a generated definition was added to, so new metrics are on screen instead of appearing to be missing.
- A Default project preference decides which project pages open on in a workspace with nothing remembered yet, or keeps returning you to where you left off.
- Environments can carry a description, shown in the environment header and as a hint on the selectors where you pick one, so a project with several similar environments explains itself at the moment of choosing.
- Result grids select like a spreadsheet: click a row number, right-click a column header, or click the corner cell, then use Ctrl+C. What is highlighted is exactly what gets copied, and the confirmation names it. Table copies are comma-separated so pasted results still read as a table wherever they land.
- The Atlas attachment picker leads with the file name and shows its folder underneath, with the full path on hover, so picking the right file out of a deep project takes a glance instead of a squint.
- Atlas writes column names exactly as your warehouse reports them, quoting case-sensitive columns, and merges into a schema file that already documents some columns without creating a duplicate entry.
- Integration credentials are visible to everyone in the organization so a teammate can reference the connection you set up, while editing or deleting stays with the owner or an organization owner or admin.
- Shared documentation portals state which environment the docs came from and present curated references read-only, so a recipient always knows what they are looking at.
- Applying an Atlas change now creates the files and folders the proposal needs instead of asking you to make an empty file first. The review step is unchanged, so nothing is written until you apply it.
- Run just the statement you are working on: Cmd+Enter runs what you highlighted, or the statement your cursor is in, so a worksheet can hold a whole set of related queries and you run them one at a time from the keyboard.
- Query results stay on screen when you leave the editor and come back, with the same rows and result tabs, and nothing re-executed against your warehouse to restore them.
- Select top 100 in editor: right-click any table in the Database Explorer to open a ready-to-run worksheet in that connection's dialect, and browse a tree ordered plainly by name instead of however the warehouse returned it.
- The dbt Cloud migration tab now hands you the export tool with a Download the CLI button and the exact commands to run, accepts the manifest by drag, file picker, or paste, and sizes the move up front: how many projects, environments, jobs, and secrets to re-enter, with the dry-run plan filterable by what will be created, skipped, unsupported, or needs a secret.
- Environment edits are harder to lose: an Unsaved changes marker in the header and a save bar that stays in view as you scroll, so Save is reachable from anywhere in a long form.
Dependable
- Deleting a workspace shows exactly what lives in it first, and stops with a named list while warehouse connections remain, so credentials and the jobs relying on them are never left stranded.
- Every commit accounts for every staged file. If a file cannot be included, it is named for you and stays in the Changes panel, so the count you committed and the work still waiting always add up.
- Change indicators in the file tree and on the Changes button read the same Git status the panel does, so a file saved back to its original contents is clean again, a folder clears once the work inside it is committed, and being behind the remote reads as its own state.
- A long session ends on your terms: an Are you still working? prompt counts down and returns you to the same page when you continue, with any open dialog work intact. A Sign out button on the same prompt ends the session everywhere at once, which is the right move on a shared machine.
- The log of a run that has already finished waits for its full output, so the log of an overnight build is there when you go looking for it.
- Restricted connections stay enforced when nobody is watching. A scheduled job or CI run is checked against its owner's real organization role, so an admin's overnight job keeps working and access is refused to everyone it should be.
- Run output explains a project variable that refers to itself, naming the cause and the two ways to resolve it, rather than reporting a parsing problem you have to decode.
- Shared documentation reads accurately at a glance: every timestamp is shown relative to now, and a connection whose workspace has been removed is clearly marked.