> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flexinference.com/llms.txt
> Use this file to discover all available pages before exploring further.

# OpenWork

> Dirigez OpenWork vers FlexInference en important un bundle de configuration OpenCode.

OpenWork pilote un backend OpenCode, le fichier que vous écrivez est donc un fichier de configuration OpenCode. Le backend y lit l'entrée du fournisseur.

OpenWork ne vous offre aucun endroit pour définir `start_within` dans son interface utilisateur, la date limite dépend donc de la clé. Créez-en une d'abord : consultez [clés d'agent](/fr/agent-keys).

## Configurer cela avec un agent

Ouvrez le bloc ci-dessous et copiez-le dans n'importe quel agent de codage. L'invite ne vous demande jamais votre clé API : l'agent configure tout le reste, puis imprime la ligne d'exportation que vous devez exécuter vous-même.

<Accordion title="Copier l'invite de configuration de l'agent">
  ```text theme={null}
  Configure OpenWork to send its requests to FlexInference. OpenWork drives an OpenCode backend, so the file you write is an OpenCode config file that OpenWork imports into its profile.

  You will never see or handle my API key. The provider entry stores only the `{env:FLEXINFERENCE_API_KEY}` template, and I export the value myself. Do not ask me for the key, and do not read it from my environment.

  1. Create a directory named `config/` beside my OpenWork checkout and put `opencode.json` in it with this content:

  {
    "$schema": "https://opencode.ai/config.json",
    "model": "flexinference/gpt-5.6-sol",
    "provider": {
      "flexinference": {
        "name": "FlexInference",
        "env": ["FLEXINFERENCE_API_KEY"],
        "npm": "@ai-sdk/openai-compatible",
        "options": {
          "apiKey": "{env:FLEXINFERENCE_API_KEY}",
          "baseURL": "https://api.flexinference.com/v1"
        },
        "models": {
          "gpt-5.6-sol": {
            "name": "GPT-5.6 Sol",
            "reasoning": true,
            "tool_call": true,
            "limit": { "context": 400000, "output": 128000 }
          }
        }
      }
    }
  }

  2. Find the OpenCode binary OpenWork should drive and note its path.

  3. Give me the launch command, with the binary path filled in:

  OPENWORK_ELECTRON_USERDATA="$PWD/.openwork-flex-userdata" \
  OPENWORK_DATA_DIR="$PWD/.openwork-flex-data" \
  OPENWORK_DEV_OPENCODE_IMPORT_CONFIG_DIR="$PWD/config" \
  OPENWORK_OPENCODE_BIN=<path to the opencode binary> \
    pnpm dev

  4. Print this line for me to run in that same shell. Do not run it and do not ask for the value:

     export FLEXINFERENCE_API_KEY=<paste your key here>

     OpenWork passes its parent environment to the backend, which is how the value reaches the provider entry.

  5. Add `.openwork-flex-userdata/` and `.openwork-flex-data/` to `.gitignore` if this is a Git repository.

  Rules that matter, do not deviate:
  - OpenWork ignores a config file in the working directory. The bundle only reaches the backend through `OPENWORK_DEV_OPENCODE_IMPORT_CONFIG_DIR`.
  - The import only runs when `OPENWORK_DEV_MODE=1`, which `pnpm dev` sets. A production launch skips it entirely.
  - Reuse the same `OPENWORK_ELECTRON_USERDATA` and `OPENWORK_DATA_DIR` paths on every launch, or you start a fresh profile and lose session history. The copy overwrites on each launch but never deletes.
  - Keep `options.apiKey` as the literal `{env:FLEXINFERENCE_API_KEY}` template. Never inline my key.
  - The top-level `model` field is what selects the provider. Without it the backend stays on its built-in default.

  Report what you created and give me the exact command to run.
  ```
</Accordion>

## Configurer OpenWork

1. Placez un fichier `opencode.json` dans un répertoire dédié. Utilisez l'entrée du fournisseur depuis [OpenCode](/fr/opencode).
2. Exportez la clé dans le shell qui démarre OpenWork.

```bash theme={null}
export FLEXINFERENCE_API_KEY=flex_live_...
```

3. Lancez OpenWork avec le chemin d'importation défini.

```bash theme={null}
OPENWORK_ELECTRON_USERDATA="$PWD/.openwork-flex-userdata" \
OPENWORK_DATA_DIR="$PWD/.openwork-flex-data" \
OPENWORK_DEV_OPENCODE_IMPORT_CONFIG_DIR="$PWD/config" \
OPENWORK_OPENCODE_BIN=/path/to/opencode/binary \
  pnpm dev
```

OpenWork maintient le backend sur un profil isolé, il ignore donc un fichier de configuration dans votre répertoire de travail. Il copie le répertoire nommé dans le profil au lancement, puis démarre le backend avec `OPENCODE_CONFIG_DIR` défini sur cette copie.

`pnpm dev` définit `OPENWORK_DEV_MODE=1`, ce qui active l'importation.

OpenWork transmet l'environnement parent au backend, de sorte que `FLEXINFERENCE_API_KEY` atteint l'entrée du fournisseur.

## La portée provient du profil, pas du dossier

OpenWork ne lit pas la configuration de votre répertoire de travail, la séparation globale et par projet qu'offre [OpenCode](/fr/opencode) ne s'applique donc pas ici. La portée provient du profil que vous utilisez au lancement.

| Portée    | Ce qui la définit                                   | S'applique à                  |
| --------- | --------------------------------------------------- | ----------------------------- |
| Un profil | `OPENWORK_ELECTRON_USERDATA` et `OPENWORK_DATA_DIR` | chaque session de ce profil   |
| Le bundle | `OPENWORK_DEV_OPENCODE_IMPORT_CONFIG_DIR`           | tout ce que le profil importe |

Conservez une paire de chemins de profil par configuration entre lesquelles vous souhaitez basculer. Le même bundle importé dans deux profils vous donne deux configurations isolées, chacune avec son propre historique de session.

Réutilisez les chemins ci-dessus pour conserver un profil. Modifiez-les pour en démarrer un nouveau.

## L'importation copie à chaque lancement et ne supprime jamais

La copie s'exécute à chaque lancement et elle écrase les fichiers existants. Modifiez le bundle, redémarrez avec les mêmes chemins `OPENWORK_ELECTRON_USERDATA` et `OPENWORK_DATA_DIR`, et le backend lira le nouveau fichier.

Elle ne supprime jamais. Un fichier que vous avez supprimé du bundle reste dans la copie du profil. Pour effacer cela, il faut de nouveaux chemins pour les deux variables, ce qui réinitialise le profil et entraîne la perte de son historique de session. Ne le faites que si un fichier résiduel pose problème.

## Confirmer l'application de la clé

Chaque réponse est accompagnée de `x-flexinference-defaults-applied`. Ni le backend ni l'interface utilisateur d'OpenWork n'affichent les en-têtes de réponse, lisez donc la requête dans le tableau de bord sous **Logs** à la place.

## Dépannage

**L'importation n'a jamais eu lieu.** C'est `OPENWORK_DEV_MODE=1` qui l'active, et `pnpm dev` le définit. Un lancement en production ignore l'importation.

**Une modification de la configuration n'a rien changé.** La copie s'exécute à chaque lancement mais uniquement sur le profil qui lui a été donné. Redémarrez avec les mêmes chemins `OPENWORK_ELECTRON_USERDATA` et `OPENWORK_DATA_DIR`.

**Un fichier que vous avez supprimé est toujours chargé.** La copie écrase mais ne supprime jamais. Démarrez un nouveau profil avec de nouveaux chemins pour les deux variables, en acceptant la perte de l'historique de session.

**Les requêtes ne nous parviennent jamais.** Le champ `model` de niveau supérieur dans le bundle est ce qui sélectionne le fournisseur. Sans lui, le backend reste sur sa valeur par défaut intégrée.

**[`401 invalid_api_key`](/fr/errors#invalid_api_key).** `FLEXINFERENCE_API_KEY` n'est pas défini dans le shell qui a démarré OpenWork. Exportez-le là, car le backend hérite de l'environnement de ce shell.

Consultez [erreurs](/fr/errors) pour chaque refus que nous renvoyons, [clés d'agent](/fr/agent-keys) pour ceux qui ne sont pas spécifiques à OpenWork, et [OpenCode](/fr/opencode) pour l'entrée du fournisseur et les options de délai par modèle.