Setup Wizard

anyy setup is the first-run configuration wizard. It walks you through picking a model provider, choosing a default model, optionally adding fallback routing, optional capabilities, and messaging channels — then writes everything to disk after a final confirmation. In the interactive wizard nothing is written until you confirm, and nothing touches your shell profile.

Non-interactive invocations apply immediately

The review-before-applying behavior covers the interactive wizard only. The non-interactive, flag-driven form anyy setup channels CHANNEL … has no final review step: it writes the channel's secret files immediately (even without --write-config), and --write-config additionally updates config.yaml.

Run it with no arguments for the full guided flow:

anyy setup

anyy setup

Interactive wizard to configure provider, model, messaging, and optional capabilities.

Usage:
  anyy setup [--home PATH]            full wizard
  anyy setup model [--home PATH]      provider/auth/default model
  anyy setup model fallback [--home PATH]
  anyy setup aux [--home PATH]        optional capabilities
  anyy setup aux CAP [--home PATH] [--probe]
  anyy setup channels [--home PATH]   messaging platforms only
  anyy setup channels CHANNEL [--home PATH] [--account-id ID] [--secret NAME=VALUE] [--set NAME=VALUE] [--write-config]
  anyy setup channels weixin login [--home PATH] [--base-url URL] [--secret NAME]
  anyy setup weixin [--home PATH] [--account-id ID] [--secret NAME=VALUE] [--set NAME=VALUE] [--write-config]
  anyy setup weixin login [--home PATH] [--base-url URL] [--secret NAME]

The subcommands (model, model fallback, aux, channels) re-run just one slice of the wizard so you can reconfigure a single thing later without walking the whole flow again. --home PATH points the wizard at an alternate home directory — handy for a throwaway profile or a second instance.

note

Anyy is provider-neutral. The providers and models you pick here are configurable backends — Anyy itself always identifies as Anyy, never as the provider or model behind it.

The wizard requires an interactive terminal. If stdin is not a TTY (for example, in a script or CI), it exits with a hint to use the non-interactive anyy setup channels CHANNEL form instead.

Full Interactive Setup

anyy setup with no subcommand runs the full flow. It opens with a Profile panel that shows exactly where settings will live before any question is asked:

◆ Anyy Setup

Profile
  Home      /Users/you/.anyy
  Config    /Users/you/.anyy/config.yaml
  Secrets   /Users/you/.anyy/secrets
  Mode      full setup

It then asks how much to configure:

• Quick setup (default) — provider, model, and messaging. Recommended for a first run.
• Full setup — everything above, plus optional capabilities and MCP servers.

From there the wizard runs these steps in order:

1. Provider & Model — select a provider, authenticate, and pick the default model (covered below).
2. Model fallback — an optional gate; declined by default.
3. Messaging — connect zero or more chat platforms.
4. Optional capabilities and MCP — Full setup only.
5. Background service — included only if you configured a channel: stage installing and starting the resident service so Anyy stays online for messages and scheduled work.
6. Review Changes — a summary of every pending change, with a final Write these changes? confirmation. The default is yes, so Enter writes the changes; answer no and nothing is written.

After a successful write, the wizard prints next-step hints (anyy status, anyy config, anyy).

If you press Ctrl-C or cancel at any prompt, the wizard reports setup canceled; no changes were written and exits cleanly.

Model Setup

To configure only the provider, authentication, and default model — without the messaging or capability steps — run:

anyy setup model

anyy setup model

Configure provider, auth, and default model.

Usage:
  anyy setup model [--home PATH]
  anyy setup model fallback [--home PATH]

This is the same Provider & Model section that the full wizard runs, so it is the quickest way to switch providers or change the default model later. For a deeper discussion of model selection, fallback, and auxiliary models, see Configuring Models.

Provider authentication

The wizard first shows a Select provider: menu. Providers are grouped by vendor — for example OpenAI offers both an API-key entry and an OAuth entry under one heading — and the menu also includes generic OpenAI-compatible, Anthropic-compatible, and custom-endpoint options for self-hosted or third-party gateways. If a provider is already configured, it is marked currently active and preselected.

After you pick a provider, the wizard prompts for authentication based on what that provider supports — an API key, an OAuth login, an optional key (which may be skipped for local endpoints), or no auth for a local model server. Keys you enter are masked and written to the secrets/ directory, never into config.yaml. The wizard will offer to reuse an existing credential if one is already on file.

This page only covers where authentication fits in the flow. For credential storage, OAuth login details, rotation, and clearing credentials, see Credentials & Auth.

Default model

Once authentication is in place, the wizard loads the provider's model catalog and shows a Select model: list. The currently active model (if any) is marked current and preselected. If the catalog cannot be fetched — or the provider has no live catalog — the wizard falls back to a Model id: prompt with a sensible default pre-filled, so you can type the model id directly.

The model you choose becomes the default for new sessions. Changing it later is just another anyy setup model run.

Fallback routing

Fallback routing lets Anyy automatically retry a request on a different provider/model when the main one fails. In the full wizard this is an optional gate (Set up model fallback routing?), declined by default. You can also configure it directly:

anyy setup model fallback

anyy setup model fallback

Configure fallback routing for the main model.

Usage:
  anyy setup model fallback [--home PATH]

A main model must already be configured first — fallback routing needs an owner. The editor lets you keep, replace, or clear the routing chain. When replacing, you build an ordered list of fallback providers from the providers you have already configured (each must have a default model). The mechanics of how fallback is chosen at runtime are covered in Configuring Models.

Auxiliary Capabilities

Optional, non-chat capabilities are configured separately. In the full wizard they live behind the Set up optional capabilities? gate (Full setup only); you can also configure them on their own:

anyy setup aux

anyy setup aux

Configure optional model capabilities.

Usage:
  anyy setup aux [--home PATH] [--probe]
  anyy setup aux CAP [--home PATH] [--probe]

Capabilities:
  image    image understanding
  video    video understanding
  imagegen image generation
  tts      text-to-speech
  stt      speech-to-text
  search   web search (coming soon)

Running anyy setup aux with no capability opens a multi-select menu; already-configured capabilities are preselected, and each row shows its current state (for example inherits main: …, configured: …, or off). Pass a single capability id (anyy setup aux tts) to configure just that one. The optional --probe flag requests a verification check for capabilities that support it (currently image generation and text-to-speech).

Capabilities split into two credential styles: image and video understanding and image generation bind to a provider you already configured, while text-to-speech and speech-to-text can point at their own endpoint.

Image generation

Configures an image-generation model bound to one of your providers, plus its generation policy. Supports --probe to verify the model after setup.

Text to speech

Configures a text-to-speech voice against an OpenAI-compatible TTS endpoint, with an option to auto-speak replies. Supports --probe.

Transcription

Speech-to-text (stt) configures an audio-understanding model so Anyy can transcribe incoming audio. It uses its own endpoint rather than binding to the main provider.

Browser and computer use

Browser and computer-use tooling is wired through MCP servers rather than the aux capability list. In the full wizard these are offered in the MCP step after optional capabilities. See Configuration for the config model and how MCP servers are represented.

Channel Setup

Messaging channels connect Anyy to chat platforms. The full wizard includes a messaging step; to configure only channels, run:

anyy setup channels

anyy setup channels

Configure messaging platforms.

Usage:
  anyy setup channels [--home PATH]
  anyy setup channels CHANNEL [--home PATH] [--account-id ID] [--secret NAME=VALUE] [--set NAME=VALUE] [--write-config]
  anyy setup channels weixin login [--home PATH] [--base-url URL] [--secret NAME]
  anyy setup weixin [--home PATH] [--account-id ID] [--secret NAME=VALUE] [--set NAME=VALUE] [--write-config]
  anyy setup weixin login [--home PATH] [--base-url URL] [--secret NAME]

With no channel argument and an interactive terminal, the wizard shows a multi-select list of platforms — Telegram, Discord, Slack, WhatsApp, Facebook, Email, SMS (Twilio), DingTalk, Feishu / Lark, Weixin / WeChat, QQ Bot, IRC, and LINE — with planned platforms shown but disabled. For each platform you pick, the wizard prompts for:

• A direct-message policy (pairing approval, allow all, allowlist, or disabled).
• A group-chat policy where supported (reply on mention, disabled, open, or allowlist).
• The platform's config fields and secret fields (tokens and keys, masked on entry). Feishu adds a connection-mode choice (long connection vs webhook); Weixin runs a QR-code login instead of a token prompt.

Passing an explicit channel name (anyy setup channels CHANNEL …) runs in non-interactive mode, taking --account-id, --secret NAME=VALUE, and --set NAME=VALUE flags and writing the config with --write-config. This is the form to use in scripts, since the interactive wizard requires a TTY.

When you configure any channel, the wizard includes installing and starting the background service so Anyy stays online to receive messages.

Status Checks

The wizard never silently overwrites your configuration: every run ends with a Review Changes summary listing the provider, model, fallback, capabilities, channels, background-service action, and how many secret files will be written (each 0600). Only after you accept Write these changes? are files written; the default answer is yes.

After setup, verify the result with the standard runtime commands the wizard points you to:

anyy status     # runtime + gateway health
anyy config     # review the written configuration
anyy doctor     # deeper checks of providers, storage, capabilities

For channels specifically, anyy channels doctor CHANNEL checks a single platform's setup.

How settings are stored

Setup writes a single config.yaml under Anyy's home directory (default ~/.anyy), and stores credentials separately as individual files under secrets/ (mode 0600). Nothing is written to your shell profile. Use --home PATH (or the ANYY_HOME environment variable) to target a different home directory. The full configuration model is documented in Configuration.

Re-running Setup

Setup is safe to re-run as often as you like — it loads your current configuration first, preselects what is already active, and only changes what you confirm. Reach for the narrowest entry point:

Goal	Command
Reconfigure everything	anyy setup
Switch provider or default model	anyy setup model
Add or edit fallback routing	anyy setup model fallback
Configure an optional capability	anyy setup aux [CAP]
Add or edit a messaging channel	anyy setup channels [CHANNEL]

Each subcommand commits independently after its own Review Changes confirmation, so reconfiguring one slice never disturbs the rest.