AltimateAI · anandgupta42 · Sep 23, 2026 · Sep 23, 2026 · Sep 23, 2026 · Sep 23, 2026
diff --git a/README.md b/README.md
@@ -60,7 +60,9 @@ altimate        # Launch the TUI
 
 Altimate Base is the free, no-signup option. It is rate limited, and its requests and responses
 are logged and may be used to improve Altimate products and services; do not send secrets or
-confidential code. The setup dialog shows this disclosure and defaults to **No** before registering.
+confidential code. If you don't pick another provider, a fresh install registers it automatically
+— no dialog to accept — and prints this notice once. Opt out with `ALTIMATE_BASE_AUTO_REGISTER=0`,
+`altimate providers logout altimate-base`, or `disabled_providers` in config.
 
 Or set an environment variable directly:
 ```bash

diff --git a/docs/docs/configure/providers.md b/docs/docs/configure/providers.md
@@ -62,23 +62,43 @@ If you need stronger guarantees — no training on your data, metadata-only rete
 [Altimate LLM Gateway](https://help.altimate.ai/datamates/user-guide/components/llm-gateway/)
 instead.
 
-Choose **Altimate Base** from the first-run picker or `/connect`. A disclosure is shown before any
-registration request; **No** is selected by default. After registration, the model is available as
+Choose **Altimate Base** from the first-run picker or `/connect` — or do nothing at all: every
+install that is not yet registered registers it automatically at startup, so it works the same way
+headlessly (`run`, `serve`, `acp`, `web`). Startup waits up to three seconds for this; a slower
+registration finishes in the background and applies from the next launch (a `serve` client can
+apply it sooner through the register route). After a failed attempt, startup skips registration
+for a retry backoff of one hour (longer if the gateway asks, up to 24 hours). This happens whether or not you
+also have a model of your own; a registered Base only becomes your default when nothing you
+configured is usable. There is no confirmation dialog to accept.
+The disclosure above is shown once per install: in the TUI as a toast the first time Base becomes
+the active model, and for a headless entrypoint as a one-line notice to stderr the first time it runs
+with Base registered (`serve` skips it when
+`ALTIMATE_CLI_CLIENT=datamates`, since the VS Code extension shows its own notice). After registration, the model is available as
 `altimate-free/altimate-base` and becomes the free fallback when no paid Altimate Gateway or
 explicit model is selected. Big Pickle is retired as a new selection — it no longer appears in the
 picker or the full model catalog for users choosing a model for the first time. Users already on
-Big Pickle are still detected on launch and offered Altimate Base through the same consent gate.
-If you decline the default switch, `declinedManagedBaseDefault: true` in the state directory's `model.json` keeps public Zen ahead of registered Base for headless and ACP defaults, with Base used only as a last resort; accepting migration or explicitly selecting Base clears the flag.
-
-Registration is per machine, not per host. Once any host on a machine has registered Altimate
-Base (the TUI's consent gate, or the HTTP registration route used by IDE integrations), every
-other host on that machine treats Base as the default free model without showing its own
-prompt: the TUI migrates an implicit free default silently, and headless `altimate run`,
-`altimate serve`, and ACP sessions resolve to Base ahead of the keyless public Zen tier. The
-disclosure is therefore shown once per machine, by whichever host registers. Declining as
-described above applies to all hosts on the machine too. Administrators auditing a fleet can
-check `model.json` for `declinedManagedBaseDefault` and the registered `altimate-free` provider
-entry in `auth.json`.
+Big Pickle are migrated to Altimate Base the same automatic way once it registers, not through a
+separate confirmation: `declinedManagedBaseDefault` is still read from `model.json` for backward
+compatibility, but no longer changes the outcome — the keyless public Zen tier rejects
+unauthenticated traffic outright, so there is no longer a working "stay on public Zen" choice to
+honor.
+
+To opt out: set `ALTIMATE_BASE_AUTO_REGISTER=0` before this install first registers Base, run
+`altimate providers logout altimate-base` afterward, or keep it out of your own choices with
+`enabled_providers` / `disabled_providers`. The env var is the only one of these that stops the
+background registration call itself; the other two only control whether Base can be *selected* as
+your model on this machine. Logging out un-registers it and also stops automatic registration on
+this machine: later launches skip it until you pick Altimate Base again in the picker (or an IDE
+calls the registration route), which reconnects it.
+
+Registration is per machine, not per host: once any host on a machine has registered Altimate
+Base (auto-registration on any entrypoint, or the HTTP registration route used by IDE
+integrations), every other host on that machine treats Base as the default free model too — the
+TUI migrates an implicit free default silently, and headless `altimate run`, `altimate serve`, and
+ACP sessions resolve to Base ahead of the keyless public Zen tier. Logging out on any host applies
+to all hosts on the machine, since the credential is a single shared file. Administrators auditing
+a fleet can check for the Altimate Base credential file, `altimate-base.json`, in the data directory
+(it is stored separately from the shared provider-auth file).
 
 Official release binaries embed the current gateway endpoint at build time. Operators and local
 development can override it without changing code:

diff --git a/docs/docs/getting-started/quickstart.md b/docs/docs/getting-started/quickstart.md
@@ -25,7 +25,7 @@ On a fresh install, a welcome panel appears with a curated 6-provider picker:
 
 - **Altimate LLM Gateway** *(recommended)* — 10M tokens free, no API keys. Routes to the best model per task across Sonnet, Opus, GPT-5, and more. Sign-in opens a browser tab; complete Google or email signup and you're back in the TUI. If your terminal can't open a browser (SSH / tmux / WSL), the CLI prints the URL — paste it into a browser on your desktop.
 - **Anthropic** / **OpenAI** / **Google** — paste an API key or OAuth in.
-- **Altimate Base** — a hosted open model, free and rate limited, with no signup or API key. Requests and responses may be logged and used to improve Altimate's products, so do not send secrets or confidential code. Registration happens only after an explicit confirmation that defaults to **No**.
+- **Altimate Base** — a hosted open model, free and rate limited, with no signup or API key. Requests and responses may be logged and used to improve Altimate's products, so do not send secrets or confidential code. Every install registers it automatically at startup, whichever provider you pick — there is no confirmation dialog — and this notice is shown once, when Base is first used; it only becomes your model when nothing else you configured is usable. Opt out with `ALTIMATE_BASE_AUTO_REGISTER=0`, `altimate providers logout altimate-base`, or `disabled_providers` (see [providers](../configure/providers.md#altimate-base)).
 - **Search all providers…** — full picker if you need Bedrock, Databricks AI Gateway, Cloudflare AI Gateway, Snowflake Cortex, DigitalOcean Inference, etc.
 
 Or set an environment variable and skip the picker:

diff --git a/docs/docs/reference/network.md b/docs/docs/reference/network.md
@@ -41,7 +41,7 @@ altimate needs outbound HTTPS access to:
 | Destination | Purpose |
 |-------------|---------|
 | Your LLM provider API | Model inference (Anthropic, OpenAI, etc.) |
-| Official Altimate Base gateway (embedded in release), or the host set by `ALTIMATE_BASE_GATEWAY_URL` | Altimate Base registration and inference when you explicitly enable Altimate Base |
+| Official Altimate Base gateway (embedded in release), or the host set by `ALTIMATE_BASE_GATEWAY_URL` | Altimate Base registration (automatic at startup on any install not yet registered, unless `ALTIMATE_BASE_AUTO_REGISTER=0`, after logging out of Base, or during the 1–24 h retry backoff after a failed attempt) and inference |
 | `registry.npmjs.org` | Package updates |
 | `models.dev` | Model catalog (can be disabled) |
 | Your warehouse endpoints | Database connections |

diff --git a/docs/docs/reference/security-faq.md b/docs/docs/reference/security-faq.md
@@ -11,13 +11,23 @@ Answers to the most common security questions about running Altimate Code in you
 
 ## Does Altimate Code send my data to external services?
 
-Altimate Code sends prompts and context to the LLM provider you configure (Anthropic, OpenAI, Azure OpenAI, AWS Bedrock, etc.). **You choose the provider.** No data is sent anywhere else except optional [telemetry](#what-telemetry-is-collected), which contains no code, queries, or credentials.
-
-Altimate Base is an optional hosted provider. Its confirmation dialog explains that requests and
-responses are logged and may be used to improve Altimate products and services; do not send
-secrets or confidential code. The dialog defaults to **No**, and no registration request is made
-unless you explicitly accept. This request logging is part of the Altimate Base service and is
-separate from anonymous product telemetry.
+Altimate Code sends prompts and context to the LLM provider you configure (Anthropic, OpenAI, Azure OpenAI, AWS Bedrock, etc.). **You choose the provider.** Beyond that provider, Altimate Code contacts the Altimate Base gateway to register this install (see below), and sends optional [telemetry](#what-telemetry-is-collected), which contains no code, queries, or credentials.
+
+Altimate Base is Altimate's own hosted free model. By default, every install that is not yet
+registered registers it automatically at startup, whether or not you also have a model of your own.
+Registration sends only a hash of a random per-install secret and the CLI version, not your prompts or code. It is skipped when
+`ALTIMATE_BASE_AUTO_REGISTER=0` is set, after you log out of Base, when no gateway is configured, and
+during the retry backoff that follows a failed attempt. There is
+no confirmation dialog to accept. It only becomes your default model when nothing you configured is
+usable. Requests and responses are
+logged and may be used to improve Altimate products and services, including the model; secrets are
+automatically masked before storage, but don't rely on it — avoid sending secrets or confidential
+code. This notice is shown once — a toast in the TUI the first time Base becomes the active model, or a one-line stderr notice the first time
+a headless entrypoint (`run`, `serve`, `acp`, `web`) runs with Base registered — and is part of the Altimate
+Base service, separate from anonymous product telemetry. To opt out: set
+`ALTIMATE_BASE_AUTO_REGISTER=0` before Base ever registers, run `altimate providers logout
+altimate-base` afterward, or exclude it from your own model choices with `enabled_providers` /
+`disabled_providers` (see [providers](../configure/providers.md#altimate-base)).
 
 **What identifies you to Altimate Base.** Registration sends a SHA-256 hash of a locally generated
 installation secret — the secret itself never leaves your machine. That hash is stable, so logged
@@ -110,7 +120,7 @@ You can also configure per-agent permissions. For example, restrict the `analyst
 | Destination | Purpose |
 |-------------|---------|
 | Your configured LLM provider | Model inference |
-| Altimate Base gateway | Registration and inference only after you explicitly enable Altimate Base |
+| Altimate Base gateway | Registration (automatic at startup on any install not yet registered) and inference |
 | Your warehouse endpoints | Database queries |
 | `registry.npmjs.org` | Package updates |
 | `models.dev` | Model catalog (can be disabled) |

diff --git a/docs/docs/reference/telemetry.md b/docs/docs/reference/telemetry.md
@@ -45,7 +45,7 @@ We collect the following categories of events:
 | `first_launch` | Fired once on the first CLI run after an install or upgrade, triggered by a marker file the installer wrote — the installers themselves send nothing and contact no telemetry endpoint. Contains the installed version, `is_upgrade`, and `install_method` (`curl`, `powershell`, `npm`, `vscode-extension`, `local` for `install --binary`, or `unknown` for markers written before the field existed). `vscode-extension` starts appearing only once an extension build containing the marker write ships, so a zero share for it means the extension has not rolled out yet rather than no extension installs. No PII. **Reading `is_upgrade`:** it means "this machine had run altimate-code before", probed as whether `~/.altimate/machine-id` already existed — *not* "a binary was already present". A reinstall onto a machine that ever ran the CLI reports `is_upgrade: true`, and `altimate uninstall` leaves `machine-id` in place, so a metric excluding upgrades counts installs **per previously-unseen machine** and undercounts reinstalls onto known ones. (`is_upgrade` is a boolean in the event schema; it arrives in Application Insights `customDimensions` as a string, so KQL filters read `tostring(customDimensions.is_upgrade) != "true"`.) Delivery is at-most-once: the marker is deleted before the event flushes, so a process that dies first loses that install rather than re-firing it every launch. Local `--binary` installs report `version: "local"`. |
 | `startup_ready` | Fired once per process when the top-level command can serve its first request or frame (`serve` listening, TUI transport resolved, `run` about to send its first prompt). Contains the command name, `duration_ms` since process start, and `fresh_install` (true when this process also emitted a non-upgrade `first_launch`). No PII. |
 | `event_loop_stall` | A 250 ms monitor tick fired more than 1 s late, meaning the event loop was blocked for that long (for example an in-process dependency install). Contains the command name, `thread` (`main` or `worker`), `blocked_ms`, and `since_start_ms`. Capped at 20 per thread (the main thread and the TUI server worker each keep their own counter). No PII. |
-| `altimate_base_registration` | Timing and outcome of each Altimate Base registration after consent (concurrent calls share one result, and a still-valid cached credential reports `success` without a network round trip): `result` (`success`, `network`, `http`, `response`, `cancelled`, `configuration`, or `error`), `duration_ms`, and the HTTP `status` when the result is `http`. Distinct from `altimate_base_register_result`, which records the onboarding-flow outcome. No gateway URL, response body, credential, or error text is included. |
+| `altimate_base_registration` | Timing and outcome of each Altimate Base registration, whether triggered automatically at startup, by an explicit picker selection, or through the `POST /altimate/base/register` route an IDE calls (`origin: "server"`) (concurrent calls share one result, and a still-valid cached credential reports `success` without a network round trip): `result` (`success`, `network`, `http`, `response`, `cancelled`, `configuration`, or `error`), `duration_ms`, and the HTTP `status` when the result is `http`. Distinct from `altimate_base_register_result`, which records the onboarding-flow outcome. No gateway URL, response body, credential, or error text is included. |
 | `task_outcome_signal` | Behavioral quality signal at session end — accepted, error, abandoned, or cancelled. Includes tool count, step count, duration, and last tool category. No user content. |
 | `task_classified` | Intent classification of the first user message using keyword matching — category (e.g. `debug_dbt`, `write_sql`, `optimize_query`), confidence score, and detected warehouse type. No user text is sent — only the classified category. |
 | `tool_chain_outcome` | Aggregated tool execution sequence at session end — ordered tool names (capped at 50), error count, recovery count, final outcome, duration, and cost. No tool arguments or outputs. |
@@ -55,10 +55,10 @@ We collect the following categories of events:
 | `validator_check` | A completion-gate validator ran on session end — validator name, `ok` boolean, step, retry count, `enforced` flag (false in shadow mode), and structured `details` (model counts, elapsed time, concurrency limit — no SQL or model content). Only emitted when `ALTIMATE_VALIDATORS_ENABLED=1` or `ALTIMATE_VALIDATORS_SHADOW=1`. See [Validators](../data-engineering/validators.md). |
 | `validator_retries_exhausted` | A session terminated with unresolved validator failures after exhausting the synthetic-retry budget — names of the failing validators (no failure body content). |
 | `onboarding_started` | The first-run setup gate opened (fresh launch with no usable model). |
-| `model_picker_shown` | The provider picker was displayed. `trigger` distinguishes the first run from `/connect`, from declining Altimate Base, and from the prompt gate. |
+| `model_picker_shown` | The provider picker was displayed. `trigger` distinguishes the first run from `/connect` and from the prompt gate (`altimate_base_back` is defined in the schema but no longer emitted — it recorded backing out of the old consent dialog, which no longer exists). |
 | `provider_selected` | A provider row was chosen — `altimate_gateway`, `altimate_base`, `anthropic`, `openai`, `google`, `search_all`, or `other` for anything outside the curated five. `provider_id` carries the raw id only for publicly-known providers, so a provider you named yourself in config is reported as `other` with no name attached. `via_search` marks a pick made inside the full catalogue after choosing "Search all providers…". **Choosing search emits this event twice for one user** — once as `search_all`, then again with the provider actually chosen — so count distinct users or filter on `via_search`, not raw event count. Recorded at the moment of choice, so a sign-in that is then cancelled still counts. |
-| `altimate_base_confirm_shown` / `altimate_base_choice` | The Altimate Base disclosure was shown, and what the user decided (`accept`/`cancel`). `origin` is `welcome`, `model`, or `migration` (returning free-default users offered Altimate Base on launch); required for the disclosure event and optional for the choice event. |
-| `altimate_base_register_result` | The consented registration outcome: `success`, `rate_limited`, `unavailable`, `network`, or `error`. Optional `origin` is `welcome`, `model`, or `migration` (returning free-default users offered Altimate Base on launch). No credential or gateway response body is included. |
+| `altimate_base_confirm_shown` / `altimate_base_choice` | Legacy — defined in the event schema but no longer emitted. These recorded the old consent dialog (shown, then `accept`/`cancel`), removed once Altimate Base moved to auto-registration with no confirmation step. |
+| `altimate_base_register_result` | The registration outcome from a picker-driven selection (the welcome picker, the full catalogue, or the provider dialog): `success`, `rate_limited`, `unavailable`, `network`, or `error`. Optional `origin` is `welcome`, `model`, or `migration` (returning free-default users offered Altimate Base). Auto-registration at startup is reported separately, by `altimate_base_registration` above. No credential or gateway response body is included. |
 | `gateway_device_code_issued` | The Altimate Gateway authorize URL was built and the browser open attempted. **Name note:** the flow is a browser loopback OAuth — there is no device code. The name follows the original event spec. |
 | `gateway_auth_completed` / `gateway_auth_failed` | Gateway sign-in outcome. `reason` is `timeout`, `denied`, or `error` — never the underlying message, which can contain the instance name. An unrecognised callback state does not reject the pending attempt, so a CSRF mismatch surfaces as `timeout`. |
 | `instance_connected` | Credentials received and saved. `time_to_connect_ms` runs from the start of the authorize call, so it includes the browser launch. No instance or tenant name is sent. |