OpenWork

OpenWork drives an OpenCode backend, so the file you write is an OpenCode config file. The backend reads the provider entry out of it. OpenWork gives you nowhere to set start_within in its own UI, so the deadline rides on the key. Create one first: see agent keys.

Set this up with an agent

Open the block below and copy it into any coding agent. The prompt never asks for your API key: the agent configures everything else, then prints the one export line for you to run yourself.

Copy agent setup prompt

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.

Configure OpenWork

Put an opencode.json in a directory of its own. Use the provider entry from OpenCode.
Export the key in the shell that starts OpenWork.
export FLEXINFERENCE_API_KEY=flex_live_...

Launch OpenWork with the import path set.

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 keeps the backend on an isolated profile, so it ignores a config file in your working directory. It copies the named directory into the profile on launch, then starts the backend with OPENCODE_CONFIG_DIR set to that copy. pnpm dev sets OPENWORK_DEV_MODE=1, which is what turns the import on. OpenWork passes the parent environment through to the backend, so FLEXINFERENCE_API_KEY reaches the provider entry.

Scope comes from the profile, not the folder

OpenWork doesn’t read config out of your working directory, so the global and per-project split that OpenCode offers doesn’t apply here. Scope comes from the profile you launch against.

Scope	What sets it	Applies to
One profile	`OPENWORK_ELECTRON_USERDATA` and `OPENWORK_DATA_DIR`	every session in that profile
The bundle	`OPENWORK_DEV_OPENCODE_IMPORT_CONFIG_DIR`	whatever the profile imports

Keep one pair of profile paths per configuration you want to switch between. The same bundle imported into two profiles gives you two isolated setups, each with its own session history. Reuse the paths above to keep a profile. Change them to start a fresh one.

The import copies on every launch and never deletes

The copy runs on every launch, and it overwrites. Edit the bundle, restart on the same OPENWORK_ELECTRON_USERDATA and OPENWORK_DATA_DIR paths, and the backend reads the new file. It never deletes. A file you removed from the bundle stays in the profile copy. Clearing that needs fresh paths for both variables, which starts the profile over and loses its session history. Do that only when a leftover file is in the way.

Confirm the key applied

Every response comes with x-flexinference-defaults-applied. Neither the backend nor the OpenWork UI shows response headers, so read the request in the dashboard under Logs instead.

Troubleshooting

The import never ran. OPENWORK_DEV_MODE=1 is what enables it, and pnpm dev sets it. A production launch skips the import. A config edit changed nothing. The copy runs per launch but only onto the profile it was given. Restart on the same OPENWORK_ELECTRON_USERDATA and OPENWORK_DATA_DIR paths. A file you deleted is still loaded. The copy overwrites but never deletes. Start a fresh profile with new paths for both variables, accepting the loss of session history. Requests never reach us. The top-level model field in the bundle is what selects the provider. Without it the backend stays on its built-in default. 401 invalid_api_key. FLEXINFERENCE_API_KEY is unset in the shell that started OpenWork. Export it there, since the backend inherits that shell’s environment. See errors for every refusal we return, agent keys for the ones that are not specific to OpenWork, and OpenCode for the provider entry and the per-model deadline options.

Get started

Concepts

Using the API

Agent Keys + Integrations

FAQ

Set this up with an agent

Configure OpenWork

Scope comes from the profile, not the folder

The import copies on every launch and never deletes

Confirm the key applied

Troubleshooting

​Set this up with an agent

​Configure OpenWork

​Scope comes from the profile, not the folder

​The import copies on every launch and never deletes

​Confirm the key applied

​Troubleshooting

Set this up with an agent

Configure OpenWork

Scope comes from the profile, not the folder

The import copies on every launch and never deletes

Confirm the key applied

Troubleshooting