---
title: "Models"
id: "1691"
type: "page"
slug: "models"
published_at: "2026-09-20T19:50:14+00:00"
modified_at: "2026-09-21T01:36:28+00:00"
url: "https://xedant.com/agents/agent/docs/models"
markdown_url: "https://xedant.com/agents/agent/docs/models.md"
excerpt: "A “model” in Xedant Agent is not just the AI model itself — it is…"
---

# Models

[https://xedant.com/agents/agent/docs/models.md](https://xedant.com/agents/agent/docs/models.md)

**A “model” in Xedant Agent is not just the AI model itself — it is a complete connection profile for an AI provider:** which backend serves your chats, which access key you use, which address the requests go to, and which prices to count. You can create several of these profiles (for example, one for Claude, one for GPT, and a cheap everyday model) and switch between them right from the chat — without restarting the program.

Nearly all agent settings are controlled through **environment variables** — startup parameters that you set once and the program applies on its own. They come in two types:

- **Application-level variables** — they configure Xedant Agent itself (the login and password for signing in, the project path, the license, keys). They are set before launch — through system environment variables, command-line arguments, or a `.env` file — and cannot be changed from the Models page;
- **Model-level variables** — they configure the AI connection and are managed entirely from the **Models** page. Each model is a named set of variables (keys, model names, addresses, prices) plus a backend. Models can be created, copied, and switched at any moment.

## Application-level variables

These variables configure Xedant Agent itself and must be set before launch. You cannot change them from the Models page — they come from system environment variables, command-line arguments (`KEY=VALUE` at startup), or a `.env` file (attached with `--env filename`).

### Main settings

- `AGENT_LOGIN` — the user name for signing in to the interface. When not set, `code` is used automatically;
- `AGENT_PASSWORD` — the password as an SHA256 hash (a hash is a “fingerprint” of the text — the original password cannot be recovered from it). When not set, one is generated automatically and printed to the console until the next restart. You can get the hash for your own password on the login page — follow the “▸ SHA256 generator” link under the sign-in button;
- `AGENT_PROJECT_PATH` — the path to the project folder. Needed for manual installs and Docker. The folder can be empty or not exist yet — then the agent fetches the project from the configured Git address itself;
- `AGENT_LICENSE` — the license key. When not set, a trial license is used;
- `AGENT_API_KEY` — an SHA256 hash of the API key for remote access. When not set, remote access is off;
- `AGENT_DATABASE` — the path to the program’s database, or a PostgreSQL connection string. The default is the `.xedant/project.db` file (SQLite) placed next to the project so you can keep it in Git. For serious use, PostgreSQL is the better choice — it is faster and more reliable than SQLite;
- `JWT_SECRET_KEY` — the secret key that signs the sign-in “passes” (JWT; minimum 32 characters). If you do not set it, a key is generated automatically. This matters for security: whoever knows the key can mint valid passes. Without your own key, recreating a Docker container regenerates it and every user has to sign in again;
- `AGENT_CLICKHOUSE_URL` — the address of a ClickHouse system (a statistics database) for collecting chat statistics into a single store. It lets you build shared charts across all your projects at once (for example, in Grafana) instead of browsing projects one by one. Example: `Host=172.17.0.1;Port=8127;Protocol=http;Database=;Username=;Password=`;
- `MANAGER_PASSWORD` — the manager password: when set, it opens access to the agent’s chats for centralized management (used by MultiAgent);
- `AGENT_BRAND` — the interface’s brand. By default it is determined by the executable file name (`XedantAgent` → Xedant, anything else → Pastukhov). It changes the product name, the logo, and the configuration folder.

### Connecting a Git repository

- `AGENT_GIT_URL` — the address of the project’s Git repository (the store of change history) to clone the project from. A demo repository is used by default;
- `AGENT_GIT_LOGIN` — the login for accessing the repository;
- `AGENT_GIT_PASSWORD` — the password for accessing the repository;
- `AGENT_GIT_USER_NAME` — the author name that will stand on the change records;
- `AGENT_GIT_USER_EMAIL` — the author email for the change records.

### The built-in FTP server

The Docker images have an FTP server built in — over FTP you can connect to the project files directly, from any file manager. Details are on the [Files](/agents/agent/docs/files)
 page.

- `AGENT_FTP_USER` — the user name for FTP access. The server starts only when both variables are set (user and password);
- `AGENT_FTP_PASSWORD` — the password for FTP access;
- `AGENT_FTP_MIN_PORT` — the lower bound of the data-transfer port range (default `30000`);
- `AGENT_FTP_MAX_PORT` — the upper bound of the range (default `30009`);
- `AGENT_FTP_ADDRESS` — the server address for connections; determined automatically by default.

### SSL and hosting

- `AGENT_SSL` — the security-certificate mode: `auto` turns on a secure connection (HTTPS) automatically, even without your own domain. Details are on the [SSL Certificates](/agents/agent/docs/ssl) page;
- `AGENT_SSL_PORT` — the HTTPS port in `AGENT_SSL=auto` mode (default: the HTTP port number + 1);
- `AGENT_SSL_DOMAINS` — an explicit comma-separated list of domains/IPs to include in the certificate;
- `AGENT_BASE_PATH` — hosts the application in a subfolder of the domain (for example, `/agent1`) instead of a separate domain. Works together with `X-Forwarded-Prefix` behind a reverse proxy.

### Miscellaneous

- `AGENT_CLAUDE_PATH` — the path to the Claude Code program (its executable), when it is not installed in the standard place;
- `AGENT_BACKEND` — the backend for chats: `claude-code` (default), `codex`, `opencode`, `pi`, `oh-my-pi`, `reasonix`, `deepseek-harness`, `kimi-code`, `mini`, or `command-code`. It is set in the model’s configuration. What backends are and how they differ — on the [Backends](/agents/agent/docs/backends) page;
- `CODEX_PATH`, `OPENCODE_PATH`, `PI_PATH`, `OMP_PATH`, `REASONIX_PATH`, `KIMI_CODE_PATH` — paths to the matching backend’s program (when it is not found automatically);
- `AGENT_YANDEX_DISK_TOKEN`, `AGENT_YANDEX_DISK_FOLDER`, `AGENT_YANDEX_DISK_POLL_INTERVAL` — remote control of the agent through Yandex Disk (including the AgentRemote desktop app). See the [Remote Control](/agents/agent/docs/remote-control) page;
- `AGENT_ICON_PATH` — the path to your own icon shown in the interface (and in the installed app’s window);
- `DISABLE_AUTOUPDATER` — set `1` to turn off automatic updates of Claude Code (usually needed in Docker);
- `DOTNET_ROOT` — the path to the .NET runtime (used by the build system);
- `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY` — internet access through a proxy (usually needed on a corporate network). The first two set the proxy address for plain and for secure connections; the third lists the addresses the proxy must bypass, for example local services. All agent engines receive these variables, so requests to AI providers and tool installs go through the proxy automatically. You can also set them at the level of a single model — so one project can connect directly while another goes through a proxy.

## Model-level variables

These variables configure the AI connection and are managed from the Models page. They live in `.xedant/models.yml` and are passed to the backend program when a chat session starts. Model variables take priority over system ones, and the system ones serve as the fallback.

### Access keys and addresses

- `ANTHROPIC_API_KEY` — the Anthropic API access key for working with Anthropic directly;
- `ANTHROPIC_AUTH` — how Claude Code signs in: `apikey` — with an Anthropic key, `claude` — with a Claude plan (Pro/Max);
- `ANTHROPIC_AUTH_TOKEN` — the access key for third-party providers (z.ai, OpenRouter, xAI, MiniMax, Kimi). An alternative to `ANTHROPIC_API_KEY`;
- `ANTHROPIC_BASE_URL` — the API address. The default is Anthropic’s address; for third-party providers it changes to theirs;
- `MAX_MCP_OUTPUT_TOKENS` — the maximum response size (in tokens) for the MCP helper servers that give the agent extra abilities. Default `100000`.

**Signing in with a Claude subscription.** When the model is set to sign in with a Claude plan (the `ANTHROPIC_AUTH=claude` variable), no access key is needed. When such a model is selected in a chat, a **“Sign in with Claude”** prompt appears at the bottom. Click it, open the link, sign in to your Claude account, and paste the code you receive — after that you will see “Signed in with Claude”, and requests run on your subscription, with no per-token billing. This sign-in is separate: it is about paying for the AI, not about access to the agent itself. Details are on the [Backends](/agents/agent/docs/backends)
 page.

### Model configuration

- `ANTHROPIC_MODEL` — the main model for replies in the chat;
- `ANTHROPIC_DEFAULT_OPUS_MODEL` — the model for hard subtasks that need maximum capability;
- `ANTHROPIC_DEFAULT_SONNET_MODEL` — the model for balanced subtasks (the best mix of speed and quality);
- `ANTHROPIC_DEFAULT_HAIKU_MODEL` — the model for quick and light subtasks;
- `CLAUDE_CODE_SUBAGENT_MODEL` — the model for the helper agents that Claude Code launches to work on small tasks in parallel;
- `MODEL` — the model for non-Anthropic backends (OpenCode, Pi, Oh My Pi, Reasonix, Codex, MiniAgent, Command Code, and others), in the format that backend expects;
- `MODEL_CONTEXT_LENGTH` — the context window size (the working memory), in tokens. Used for cost calculation and for the fill display.

### Prices (per million tokens)

Tokens are the “units of text” you pay the provider for. Here you set the rates the agent uses to count your spending:

- `MODEL_INPUT_PRICE` — the price of the text sent to the model (your messages, file contents);
- `MODEL_OUTPUT_PRICE` — the price of the text the model generates in reply;
- `MODEL_CACHE_READ_PRICE` — the price of a cache read: processing text the model has already seen comes cheaper;
- `MODEL_CACHE_WRITE_PRICE` — the price of writing text into the cache.

### Behavior controls

- `CLAUDE_DISABLE_EXPERIMENTAL_BETAS` — `true` turns off experimental features (recommended for third-party providers that do not support them);
- `DISABLE_NON_ESSENTIAL_MODEL_CALLS` — `true` turns off secondary calls to the model (also recommended for third-party providers — it saves both money and time);
- `ENABLE_TOOL_SEARCH` — `false` turns off tool search (used for some providers that do not support it);
- `MODEL_PEAK_HOURS` — the “rush hour” windows when the provider charges more. Together with `MODEL_PEAK_DAYS`, it decides when a warning icon appears next to the model selector. Details are in the Peak hours section below.

**Note:** when you create a model from a built-in provider template (Anthropic, z.ai, OpenRouter, DeepSeek, and others), most variables are filled in automatically — including the backend. All you need is the access key: the template fills in the model names, the address, the prices, and the behavior settings. See [Setting up your first model](/agents/agent/docs/getting-started#setting-up-your-first-environment)
 in the Getting Started guide.

## Peak hours

Some providers charge more during their peak load hours. A model can declare its peak windows — the agent will then warn you in the interface and will not spend money on automatic runs during them.

### Peak-hours variables

- `MODEL_PEAK_HOURS` — comma-separated start-end windows in the `H:MM-H:MM` format. Time is set in GMT/UTC. Example: `3:00-5:00,7:00-12:00` . Crossing midnight is supported — the `23:00-1:00` window runs from 23:00 to 1:00. When the variable is not set, the model has no peak hours — it is never considered “in peak”;
- `MODEL_PEAK_DAYS` — days of the week as English names, comma-separated, full or abbreviated (`monday, tuesday` or `mon, tue` and so on). The default peak days are Monday–Friday; setting your own variable overrides them (for example, `saturday,sunday`).

Both variables are set in the model editor the usual way: the “Add Variable” button and a name — value pair. Both name-segment inheritance and `$NAME` substitution work here — including references to system environment variables (see the “Settings inheritance” and “Variable substitution” sections below).

### The on-screen indicator

- **Where:** next to the model selector in the message input panel;
- **When:** only when the selected model is currently inside its peak window (the hours and days from its variables);
- **Look:** a warning icon — a gradient triangle with an exclamation mark;
- **Tooltip:** “Model peak hours from HH:MM to HH:MM, more expensive” — the time is shown in your local time zone (the GMT value is converted);
- **Refresh:** every 30 seconds, and on every model switch.

### Peak-hours behavior settings

Two settings control automatic behavior during peak hours — prompt auto-send and button autoclick. Both are on by default.

| Setting | Default | Where in the interface | When turned off |
| --- | --- | --- | --- |
| promptsIgnorePeakHours | on | AutoSend on the Prompts page | prompts whose model is currently in peak wait in the queue; prompts of off-peak models are still sent |
| autoclickDuringPeakHours | on | the “Buttons” card on the Settings page | autoclickable buttons in chats on the peak-hours model do not fire on their own — they wait for a manual click |

**`promptsIgnorePeakHours`.** The “Send during peak hours” switch in the AutoSend settings (the “AutoSend settings” popover next to the auto-send switch). While it is on (the default), auto-send works as usual and peaks are ignored: prompts are sent even when the model is in peak. Turning it off stops auto-sending prompts whose model is currently in peak: those rows wait in the queue and are sent once the peak ends.

**`autoclickDuringPeakHours`.** The “Autoclick during peak hours” switch in the “Buttons” card (Settings → Automation). While it is on (the default), autoclickable buttons fire on schedule even inside the chat model’s peak hours. Turn it off — and buttons in chats whose model is currently in peak will not fire on their own; they stay available for a manual click.

### Example: weekend peaks

A “Weekend” model with `MODEL_PEAK_HOURS=18:00-22:00` and `MODEL_PEAK_DAYS=saturday,sunday`:

- every Saturday and Sunday from 18:00 to 22:00 GMT, the warning icon appears next to the model selector (the tooltip shows the same hours in your local time);
- while `promptsIgnorePeakHours` is on, this model’s prompts are sent as usual; turn it off — and on weekend evenings they wait in the queue until the peak ends, while other models’ prompts keep sending;
- turning `autoclickDuringPeakHours` off means autoclickable buttons in chats on the “Weekend” model do not fire on their own during those hours — only manual clicks remain.

## What is a model?

A model is a named set of settings that decide how the AI answers your messages: the provider access key, the model name, the API address, the prices, and the chosen backend (which engine works under the hood). Instead of one key and one model hard-coded into the program, you create several model configurations and switch between them on the fly.

For example, you can create:

- **Claude** — the Claude Code backend, an Anthropic key, and a Claude model;
- **GPT** — the Codex backend, a ChatGPT subscription or an OpenAI key, and the GPT-5 model;
- **GLM** — the Claude Code backend, a z.ai key, and a GLM model;
- **DeepSeek** — the Reasonix or DeepSeek Harness backend, a DeepSeek key, pay per token (an inexpensive option for everyday work);
- **Testing** — a cheap or fast model for experiments.

Each model has its own set of variables. When you switch, the AI immediately starts working with the new configuration — from the very next message.

**Settings inheritance.** Model names support inheritance across the segments separated by a hyphen. The `glm-5-turbo` model automatically inherits the variables of the `glm-5` and `glm` models. This lets you set shared settings (say, the key and the address) once in a “parent” model, and override only the differences (the model name or the prices) in the “children”. A model’s own variables always beat the inherited ones.

**Backends.** Every model can run on any of the ten engines: Claude Code, Codex, OpenCode, Pi, Oh My Pi, Reasonix, DeepSeek Harness, Kimi Code, MiniAgent, or Command Code. The backend is set with the `AGENT_BACKEND` variable inside the model, so you can keep several models on different engines and switch between them. Details are on the [Backends](/agents/agent/docs/backends)
 page.

## Viewing models

You manage models in the Models dialog, opened from the model selector in the chat input area (the “Manage models” item). The dialog shows the list of all configured models with their colors and main settings. Click a model to open its editor and view or change all of its variables.

 ![The list of models in Xedant Agent](https://xedant.com/wp-content/uploads/2026/06/environments-viewing-environments.png) ## Editing a model

The editor shows all the variables as name — value pairs. Set the model up here; the changes save on their own.

 ![The model editor with name-value pairs](https://xedant.com/wp-content/uploads/2026/06/environments-detail-page.png) **Change a variable:** click the value field and type the new one. The change saves automatically after a short pause — no save button is needed.

**Add a variable:** click “Add Variable” to create a new name — value pair.

**Add a reference variable:** to create a variable whose value refers to another variable, add it with “Add Variable” and give the value the `$NAME` form (for example, `$MY_API_KEY`). Handy for a tidy configuration (see the Variable substitution section below).

**Change the order:** drag variables up or down. This is only for tidiness — the position does not affect how variables work.

**Context menu:** the menu next to the model’s name in the editor offers extra actions — copy, paste, clone, and delete.

## Variable substitution

Variables can refer to other variables — the syntax is `$VARIABLE_NAME`. When a model is used, the references expand into the real values automatically.

For example:

- `API_KEY` = `sk-abc123...` (your real access key)
- `BASE_URL` = `https://api.example.com`
- `FULL_ENDPOINT` = `$BASE_URL/v1/chat` (refers to BASE_URL)

This keeps the configuration clean: change the address once, and every variable referring to it updates automatically. And an access key can be set in one place and referenced from everywhere.

**Security tip:** the `$VARIABLE_NAME` syntax also works with system environment variables. That means secrets (access keys, licenses, passwords) can be passed through Docker environment variables, system variables, or launch arguments, while `models.yml` only references them — and the secrets never land in the repository:

```
# .xedant/models.yml — safe to keep in Git
models:
  production:
    variables:
      - ANTHROPIC_API_KEY=$MY_API_KEY          # taken from the system variable at startup
      - ANTHROPIC_AUTH_TOKEN=$MY_AUTH_TOKEN     # the secret is not stored in the file
      - ANTHROPIC_BASE_URL=https://api.anthropic.com  # not a secret — fine to store openly
```

The real secret values stay in the Docker configuration (a compose file, `.env`, or `-e` flags), and `models.yml` can be safely kept in Git and shared with colleagues.

## Creating a new model

 ![The new model wizard in Xedant Agent](https://xedant.com/wp-content/uploads/2026/06/environments-new-environment.png) 1. Open the Models dialog from the model selector in the chat input area;
2. Click “New model”;
3. Pick a provider template (Anthropic, z.ai, OpenRouter, DeepSeek, Codex, Reasonix, OpenCode, Pi, Oh My Pi, DeepSeek Harness, Kimi Code, and others) — the template fills in the backend, the key variables, the models, and the prices;
4. Enter your access key (or sign in to an account when the template expects a subscription — for models on a Claude subscription, the chat will show the “Sign in with Claude” prompt);
5. Type the model’s name (for example, “Claude” or “GPT-5”);
6. The model is ready — switch to it from the chat input field.

## Renaming a model

Click the model’s name in the editor, type the new name, and confirm. The change applies everywhere the model appears — including the selector in the chat input field. References to the model in tasks and bots are renamed automatically.

## Switching models in a chat

The fastest way to switch models is right from the chat input area:

 ![The model selector in the message input area](https://xedant.com/wp-content/uploads/2026/06/environments-switching-environments-chat.png) 1. Find the model dropdown next to the chat input field;
2. Click it — the list of available models opens;
3. Pick the model you need;
4. All the following messages go through it.

Switching is instant — no need to restart the chat or reload the page: the AI applies the new settings from the next message on. More about the input area is in the [Chat](/agents/agent/docs/chat)
 section.

**[← Skills](/agents/agent/docs/skills)**

**[Prompts →](/agents/agent/docs/prompts)**