> ## Documentation Index > Fetch the complete documentation index at: https://novita.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Configuration Configurez les modèles, connectez des canaux de messagerie externes, configurez le mode à la demande et comprenez les fonctionnalités de fiabilité du service de votre instance NovitaClaw. ## Mode à la demande Le mode à la demande met automatiquement votre sandbox en pause après une période d’inactivité configurable et le reprend lorsqu’il est consulté. Idéal pour les assistants IA à faible trafic, les intégrations IM basées sur des webhooks et les tâches planifiées. Aucune facturation pendant la pause. ### Lancer une sandbox à la demande ```bash Bash icon="terminal" theme={"system"} # Default idle timeout: 300 seconds novitaclaw launch --type on-demand # Custom idle timeout (60–86400 seconds) novitaclaw launch --type on-demand --idle-timeout 600 ``` Le mode à la demande ne peut pas être combiné avec `--mode node`. ### Pause et reprise manuelles ```bash Bash icon="terminal" theme={"system"} # Pause a sandbox (zero billing while paused) novitaclaw pause # Resume a sandbox (~1s to restore to pre-pause state) novitaclaw resume ``` ### Configuration d’exécution ```bash Bash icon="terminal" theme={"system"} # Update idle timeout (60–86400 seconds) novitaclaw config set idle-timeout 600 # Update sandbox lifetime timeout (300–2592000 seconds) novitaclaw config set timeout 3600 ``` Les modifications prennent effet immédiatement. L’agent dans la sandbox récupère la nouvelle configuration lors de son prochain cycle de vérification. ### Fonctionnement 1. **Détection de l’inactivité** — Un daemon d’agent à l’intérieur de la sandbox vérifie périodiquement l’activité des sessions OpenClaw et écrit l’état dans `/tmp/.novitaclaw-status.json`. 2. **Pause automatique** — Le moniteur d’inactivité côté serveur lit l’état de l’agent. Après 2 vérifications d’inactivité consécutives, la sandbox est automatiquement mise en pause. 3. **Reprise automatique** — Les requêtes webhook entrantes ou l’accès à l’interface Web reprennent automatiquement une sandbox mise en pause. 4. **Pré-réveil cron** — Le planificateur analyse les sandboxes en pause à la recherche de planifications cron à venir et les reprend environ 120 secondes avant le déclenchement de la prochaine tâche, afin de garantir que les tâches cron s’exécutent à l’heure. ### Vérifier l’état ```bash Bash icon="terminal" theme={"system"} # View sandbox status (does not trigger resume when paused) novitaclaw status # List shows sandbox_type and state columns novitaclaw list ``` Pendant la pause, la commande `status` renvoie toujours les informations d’URL complètes (lues depuis la base de données sans se connecter à la sandbox), ce qui permet aux scripts d’enregistrer les adresses sans déclencher de reprise. ## Configurer les modèles Votre instance est préconfigurée avec un modèle hébergé par Novita prêt à l’emploi. Pour modifier les modèles utilisés par votre agent, accédez à `Settings → Config`, cliquez sur **Raw** pour passer à la vue JSON5 brute, puis cliquez sur le bouton de révélation à côté de "secrets redacted" pour afficher la configuration complète. Mettez à jour les deux sections suivantes : ### Étape 1 : enregistrer le modèle sous votre fournisseur Ajoutez un nouvel objet au tableau `models` à l’intérieur de `models.providers.novita` : ```json theme={"system"} { "models": { "providers": { "novita": { "models": [ { "id": "model-id", "name": "display name", "reasoning": true, "input": ["text"], "contextWindow": 200000, "maxTokens": 50000 } ] } } } } ``` ### Étape 2 : le définir comme modèle principal ou de secours Mettez à jour le champ `model` sous `agents.defaults` pour référencer votre modèle au format `provider/model-id` : ```json theme={"system"} { "agents": { "defaults": { "model": { "primary": "novita/model-id", "fallbacks": ["novita/fallback-model-id"] } } } } ``` Cliquez sur **Update** pour enregistrer. Tous les LLM disponibles sur la [plateforme Novita](https://novita.ai/model-api/product/llm-api) sont pris en charge. Les fournisseurs tiers peuvent également être configurés — lorsque vous apportez votre propre LLM, vous ne payez que l’exécution de la sandbox, et non l’utilisation des modèles Novita. Configuration du modèle NovitaClaw ## Connecter des canaux OpenClaw prend en charge les canaux de messagerie externes afin que votre agent soit joignable en dehors de l’interface Web. Les canaux sont désactivés par défaut et doivent être configurés. ### Telegram Connectez votre agent à Telegram en tant que canal de messagerie. Deux modes de connexion sont pris en charge : **Polling** (par défaut, long-poll — aucune URL publique requise) et **Webhook** (push HTTP — idéal pour les sandboxes à la demande). **Étape 1 : créer un bot Telegram** 1. Ouvrez Telegram et recherchez [@BotFather](https://t.me/BotFather). 2. Envoyez `/newbot` et suivez les invites pour nommer votre bot. 3. Copiez le token de bot fourni par BotFather. #### Mode 1 : Polling Le mode Polling utilise des connexions long-poll. Aucune URL publique n’est requise — c’est le plus simple à configurer. Le mode Polling n’est pas recommandé pour les sandboxes à la demande. Lorsque la sandbox se met automatiquement en pause, la connexion est interrompue et les messages entrants sont perdus. Utilisez le mode Webhook pour les sandboxes à la demande. ```bash Bash icon="terminal" theme={"system"} novitaclaw pair telegram \ --bot-token ``` #### Mode 2 : Webhook Le mode Webhook nécessite que la sandbox expose un port HTTP pour recevoir les événements push de Telegram. Il convient le mieux aux sandboxes à la demande — les requêtes webhook entrantes déclenchent automatiquement la reprise. Le `--webhook-url` est l’URL publique attribuée à votre sandbox. Exécutez la commande suivante pour la récupérer : ```bash Bash icon="terminal" theme={"system"} novitaclaw status --json | jq -r '.telegram_webhook_url' ``` ```bash Bash icon="terminal" theme={"system"} novitaclaw pair telegram \ --bot-token \ --mode webhook \ --webhook-url \ --webhook-secret ``` #### Paramètres Webhook facultatifs | Paramètre | Valeur par défaut | Description | | ---------------- | ------------------- | ------------------------------------- | | `--webhook-host` | `0.0.0.0` | Adresse de liaison du serveur webhook | | `--webhook-port` | `8787` | Port d’écoute du webhook | | `--webhook-path` | `/webhook/telegram` | Chemin d’URL du webhook | | `--dm-policy` | `pairing` | Politique DM | #### Flux d’appairage Lors de la première conversation, le bot répond avec un code d’appairage : ```bash Bash icon="terminal" theme={"system"} # List pending pairing requests novitaclaw pair list --channel telegram # Approve a pairing request novitaclaw pair approve --channel telegram --code ``` #### Comparaison des modes | | Polling | Webhook | | -------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------- | | Connexion | Sortante (long-poll) | Entrante (push HTTP) | | Port public | Non requis | Requis | | Complexité de configuration | Faible | Moyenne (secrets supplémentaires) | | Reprise automatique à la demande | Non prise en charge (la connexion est interrompue lors de la pause) | Prise en charge (le webhook déclenche la reprise) | | Recommandé pour | Sandboxes toujours actives, développement | Sandboxes à la demande, IM de production | ### Slack Connectez votre agent à Slack en tant que canal de messagerie. Deux modes de connexion sont pris en charge : **Socket** (par défaut, WebSocket — aucune URL publique requise) et **HTTP** (webhook Events API — idéal pour les sandboxes à la demande). #### Mode 1 : Socket Le mode Socket utilise une connexion WebSocket. Aucune URL publique n’est requise — c’est le plus simple à configurer. Le mode Socket n’est pas recommandé pour les sandboxes à la demande. Lorsque la sandbox se met automatiquement en pause, la connexion WebSocket est interrompue et les messages entrants sont perdus. Utilisez le mode HTTP pour les sandboxes à la demande. ```bash Bash icon="terminal" theme={"system"} novitaclaw pair slack \ --bot-token xoxb-... \ --app-token xapp-... ``` #### Mode 2 : HTTP Le mode HTTP utilise les webhooks Slack Events API. Il convient le mieux aux sandboxes à la demande — les requêtes webhook entrantes déclenchent automatiquement la reprise. ```bash Bash icon="terminal" theme={"system"} novitaclaw pair slack \ --bot-token xoxb-... \ --mode http \ --signing-secret ``` #### Paramètres HTTP facultatifs | Paramètre | Valeur par défaut | Description | | ---------------- | ----------------- | ------------------------------------- | | `--webhook-host` | `0.0.0.0` | Adresse de liaison du serveur webhook | | `--webhook-port` | `8788` | Port d’écoute du webhook | | `--webhook-path` | `/webhook/slack` | Chemin d’URL du webhook | #### Flux d’appairage Lors de la première conversation, le bot répond avec un code d’appairage : ```bash Bash icon="terminal" theme={"system"} # List pending pairing requests novitaclaw pair list --channel slack # Approve a pairing request novitaclaw pair approve --channel slack --code ``` #### Comparaison des modes | | Socket | HTTP | | -------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------- | | Connexion | WebSocket (sortante) | Push HTTP (entrant) | | Port public | Non requis | Requis | | Complexité de configuration | Faible | Moyenne (secrets supplémentaires) | | Reprise automatique à la demande | Non prise en charge (la connexion est interrompue lors de la pause) | Prise en charge (le webhook déclenche la reprise) | | Recommandé pour | Sandboxes toujours actives, développement | Sandboxes à la demande, IM de production | ### État des canaux `novitaclaw status` affiche les URL webhook pour tous les canaux configurés : ```bash Bash icon="terminal" theme={"system"} novitaclaw status # Shows: Feishu Webhook, Telegram Webhook, Slack Webhook (when configured) # JSON mode novitaclaw status --json | jq -r '.feishu_webhook_url' novitaclaw status --json | jq -r '.telegram_webhook_url' novitaclaw status --json | jq -r '.slack_webhook_url' ``` ### Feishu Connectez votre agent à Feishu (Lark) en tant que canal de messagerie. Deux modes de connexion sont pris en charge : **Webhook** (push HTTP) et **Event** (long-poll WebSocket). #### Prérequis : créer une application Feishu 1. Ouvrez la [Feishu Open Platform](https://open.feishu.cn/app), connectez-vous et cliquez sur **Create Custom App**. 2. Sur la page **Credentials & Basic Info**, copiez : * **App ID** (format : `cli_xxx`) * **App Secret** 3. Accédez à **Permission Management**, cliquez sur **Batch Import**, puis collez les autorisations suivantes : ```json theme={"system"} { "scopes": { "tenant": [ "im:message", "im:message:send_as_bot", "im:message:readonly", "im:message.p2p_msg:readonly", "im:message.group_at_msg:readonly", "im:resource", "im:chat.access_event.bot_p2p_chat:read", "im:chat.members:bot_access" ], "user": ["im:chat.access_event.bot_p2p_chat:read"] } } ``` 4. Accédez à **App Capabilities > Bot** et activez la capacité de bot. 5. Créez une version et publiez l’application. #### Mode 1 : Webhook Le mode Webhook nécessite que la sandbox expose un port HTTP pour recevoir les événements push de Feishu. Il convient le mieux aux sandboxes à la demande — les requêtes webhook entrantes déclenchent automatiquement la reprise. **Identifiants supplémentaires :** sur la Feishu Open Platform, accédez à **Development Configuration > Events & Callbacks > Encryption Strategy** et copiez : * **Verification Token** * **Encrypt Key** ```bash Bash icon="terminal" theme={"system"} novitaclaw pair feishu \ --app-id cli_xxx \ --app-secret secret_xxx \ --mode webhook \ --verification-token tok_xxx \ --encrypt-key key_xxx ``` Sur la page **Event Subscription** de la Feishu Open Platform : 1. Sélectionnez **Request URL Configuration** 2. Saisissez l’URL Webhook — récupérez-la via : ```bash Bash icon="terminal" theme={"system"} novitaclaw status --json | jq -r '.feishu_webhook_url' ``` 3. Ajoutez l’événement : `im.message.receive_v1` #### Mode 2 : Event Le mode Event utilise une connexion long-poll WebSocket Feishu. Aucune URL publique n’est requise — c’est le plus simple à configurer. Le mode Event n’est pas recommandé pour les sandboxes à la demande. Lorsque la sandbox se met automatiquement en pause, la connexion WebSocket est interrompue et les messages entrants sont perdus. Utilisez le mode Webhook pour les sandboxes à la demande. ```bash Bash icon="terminal" theme={"system"} novitaclaw pair feishu \ --app-id cli_xxx \ --app-secret secret_xxx ``` Après la configuration, sur la page **Event Subscription** de la Feishu Open Platform : 1. Sélectionnez **Use Long Connection to Receive Events** 2. Ajoutez l’événement : `im.message.receive_v1` Assurez-vous que la gateway est en cours d’exécution (`novitaclaw status `) avant d’enregistrer, sinon Feishu peut ne pas parvenir à enregistrer la configuration de connexion longue. #### Paramètres Webhook facultatifs | Paramètre | Valeur par défaut | Description | | ---------------- | ----------------- | ------------------------------------- | | `--webhook-host` | `0.0.0.0` | Adresse de liaison du serveur webhook | | `--webhook-port` | `3000` | Port d’écoute du webhook | | `--webhook-path` | `/feishu/events` | Chemin d’URL du webhook | #### Flux d’appairage Feishu utilise une stratégie `pairing` par défaut. Lors de la première conversation, le bot répond avec un code d’appairage qui doit être approuvé via la CLI : ```bash Bash icon="terminal" theme={"system"} # List pending pairing requests novitaclaw pair list --channel feishu # Approve a pairing request novitaclaw pair approve --channel feishu --code ``` #### Comparaison des modes | | Event | Webhook | | -------------------------------- | ----------------------------------------- | ------------------------------------------------- | | Connexion | Long-poll WebSocket (sortant) | Push HTTP (entrant) | | Port public | Non requis | Requis (par défaut 3000) | | Complexité de configuration | Faible (App ID + Secret uniquement) | Moyenne (Token + Key supplémentaires) | | Reprise automatique à la demande | Non prise en charge | Prise en charge (le webhook déclenche la reprise) | | Recommandé pour | Sandboxes toujours actives, développement | Sandboxes à la demande, IM de production | ## Fiabilité du service Tous les services principaux de la sandbox sont gérés par systemd pour une fiabilité de niveau production : | Service | Description | Redémarrage automatique | | --------------------------- | --------------------------------------- | ----------------------- | | OpenClaw Gateway | Runtime de l’agent et serveur WebSocket | ✅ | | Web Terminal (ttyd) | Accès au terminal depuis le navigateur | ✅ | | File Manager (gohttpserver) | Gestion des fichiers depuis le Web | ✅ | **Récupération automatique après crash :** si la Gateway plante de manière répétée, le système exécute automatiquement des diagnostics, tente une réparation et restaure la dernière configuration connue comme fonctionnelle depuis une sauvegarde — aucune intervention manuelle n’est requise. **Sauvegarde automatique de la configuration :** chaque écriture de configuration crée une sauvegarde automatique. Si une mauvaise configuration provoque un crash, le processus de récupération restaure la sauvegarde valide la plus récente.