Skip to main content
The CLI resolves settings in this order:
  1. CLI flags
  2. Environment variables
  3. ~/.config/tensormesh/config.toml
  4. Built-in defaults
For the Control Plane host specifically, use --controlplane-base, TENSORMESH_CONTROL_PLANE_BASE_URL, or top-level controlplane_base in config.toml. If you need an alternate local state root for scripting or side-by-side environments, set TM_CONFIG_HOME. That moves both config.toml and auth.json together under the directory you choose. Within config.toml, gateway values resolve in this order:
  1. [overrides]
  2. [managed]
Use tm config show --sources when you need to confirm which layer actually won for each value.

​
Create A Starter Config

tm config init
tm config show
tm config show --sources
To write the starter template to a custom location: 
tm config init --path ./tensormesh.toml
tm --config ./tensormesh.toml config show

​
Canonical Config File

The standard persistent CLI setup lives in: ~/.config/tensormesh/config.toml Or, when TM_CONFIG_HOME is set:
  • config: $TM_CONFIG_HOME/config.toml
  • auth: $TM_CONFIG_HOME/auth.json
The standard flow is: 
tm config init
tm auth login
tm init --sync
tm config init creates the file with user-owned request settings plus two gateway sections:
  • [managed]: written by tm init --sync
  • [overrides]: optional manual gateway overrides
tm init --sync syncs the available gateway settings from the Control Plane, then updates [managed]. When the command runs with --controlplane-base, it also persists that controlplane_base into the active config.toml. A session-only TENSORMESH_CONTROL_PLANE_BASE_URL override still wins while it is set, but tm init --sync does not write that env override into config.toml. When a served deployment already exists, that includes the gateway provider and served model name. When no served model exists yet, the sync can still write the API key and user id while leaving gateway_model_id unset: 
[managed]
synced_at = "2026-03-23T00:00:00Z"
gateway_provider = "nebius"
gateway_api_key = "..."
gateway_user_id = "00000000-0000-0000-0000-000000000000"
gateway_model_id = "your-served-model-name"
Manual [overrides] values in config.toml still win over [managed], and env vars still win over both.

​
Config File Schema

The starter template is the real schema the CLI understands today: 
# controlplane_base = "https://api.tensormesh.ai"
timeout_seconds = 30
max_retries = 0
# ca_bundle = "~/.config/tensormesh/ca-bundle.pem"

[overrides]
# gateway_provider = "nebius"
# gateway_api_key = "..."
# gateway_user_id = "00000000-0000-0000-0000-000000000000"
# gateway_model_id = "..."

[managed]
# synced_at = "2026-03-23T00:00:00Z"
# gateway_provider = "nebius"
# gateway_api_key = "..."
# gateway_user_id = "00000000-0000-0000-0000-000000000000"
# gateway_model_id = "your-served-model-name"
Top-level keys:
  • controlplane_base: optional Control Plane base URL override for auth, sync, and other Control Plane commands
  • timeout_seconds: default HTTP timeout for commands that use the shared request client
  • max_retries: default retry count for idempotent requests
  • ca_bundle: optional PEM CA bundle path for TLS verification
Gateway sections:
  • [managed]: synced values owned by tm init --sync
  • [overrides]: optional manual overrides for provider, API key, user id, and served model name
gateway_api_key is the shared inference API key for both On-Demand and Serverless requests. The name stays gateway_api_key for config compatibility, even when you are only using tm infer chat --surface serverless. gateway_api_key is the stored inference API key used by the SDK as inference_api_key. gateway_model_id remains a config compatibility key; its value is the served model name string sent as model. Top-level gateway_* keys are no longer read. Move manual values into [overrides], or run tm init --sync to refresh [managed]. gateway_base is not configured directly. The CLI derives it from gateway_provider.

​
Single-File Design

The CLI now uses a single canonical config file. If you want to change gateway behavior manually, edit [overrides] in ~/.config/tensormesh/config.toml instead of switching between named profiles or maintaining a separate runtime file. If you want that same single-file design in a different local root, set TM_CONFIG_HOME instead of introducing another profile layer. Example: 
controlplane_base = "https://api.tensormesh.ai"
timeout_seconds = 20
max_retries = 1

[overrides]
gateway_provider = "yotta"
gateway_model_id = "my-model"
Inspect the resolved config and sources: 
tm --config ./tensormesh.toml config show --sources
tm doctor, tm infer doctor, and tm auth status report local config and credential presence. Use tm auth whoami when you need a live Control Plane auth check.

​
Interpreting config show --sources

Use --sources when debugging precedence: 
tm --output json config show --sources
The result contains:
  • values: resolved config after redacting secrets such as gateway_api_key
  • sources: where each value came from, such as config:timeout_seconds, managed:gateway_api_key, or derived-from:managed:gateway_provider
Typical source strings:
  • built-in:config_path: CLI default
  • TENSORMESH_CONTROL_PLANE_BASE_URL: environment override for the Control Plane base URL
  • managed:gateway_api_key: synced value from [managed] in ~/.config/tensormesh/config.toml
  • derived-from:managed:gateway_provider: computed value, such as gateway_base, derived from a synced managed provider
  • config:controlplane_base: explicit top-level Control Plane host from config.toml
  • config:gateway_provider: explicit user override from [overrides] in config.toml
tm config show and tm config show --sources redact secrets such as gateway_api_key in both text and JSON output. That is intentional. To access the unredacted key, read the config file directly as shown in the Exporting Managed Values section below.

​
Exporting Managed Values For Automation

If you need to bridge CLI-managed local state into a controlled shell script, read the local config file directly instead of scraping redacted tm config show output. Example: 
eval "$(
python3 - <<'PY'
from pathlib import Path
import shlex
import os
import tomllib

config_root = Path(
    os.environ.get("TM_CONFIG_HOME", "~/.config/tensormesh")
).expanduser()
config_path = config_root / "config.toml"
data = tomllib.loads(config_path.read_text(encoding="utf-8"))
managed = data.get("managed", {})

for env_name, key in (
    ("GATEWAY_API_KEY", "gateway_api_key"),
    ("GATEWAY_USER_ID", "gateway_user_id"),
    ("GATEWAY_MODEL_NAME", "gateway_model_id"),
):
    value = managed.get(key)
    if value:
        print(f"export {env_name}={shlex.quote(str(value))}")
PY
)"
Use this only in controlled local automation. Do not paste these exports into shared logs or CI output.

​
Environment Variables

VariableOverrides flagDescription
TENSORMESH_CONTROL_PLANE_BASE_URL--controlplane-baseOverride the Control Plane base URL for CLI auth and Control Plane requests.
TENSORMESH_CA_BUNDLE--ca-bundlePath to a PEM CA bundle for TLS verification.
TENSORMESH_TIMEOUT_SECONDS--timeoutDefault HTTP timeout in seconds.
TENSORMESH_MAX_RETRIES--max-retriesMax retries for idempotent requests on transient errors.
TM_CONFIG_HOME—Override the config and auth root directory. Moves both config.toml and auth.json to $TM_CONFIG_HOME/.
Gateway credentials — gateway_api_key, gateway_user_id, and gateway_model_id — do not have environment variable equivalents in the CLI. Set them in [overrides] in config.toml, or use tm init --sync to populate [managed]. If you need an environment-variable-only credential workflow without a config file, use the Tensormesh SDK instead, which supports TENSORMESH_INFERENCE_API_KEY and related credential variables.