Skip to main content
Values in NiceEval have only two homes:
  • Configuration lives in code—CLI flags, Experiment files under experiments/, and niceeval.config.ts at the root. Attempt count, timeout, concurrency, and the Judge model all live here; none has a corresponding environment variable.
  • Secrets live in environment variables—API keys and Provider tokens, plus facts such as NO_COLOR that describe the terminal receiving output.
Every value therefore has one source. What niceeval exp --dry prints is what actually takes effect; no environment variable changes it in the background. CLI and runtime text are English. Browser view has its own English/Chinese language switch.

Configuration: choose a layer by how long the value should live

When the same value appears at several layers, precedence is CLI flag → Experiment → eval → config → built-in default. The first present value wins. Config is a default source, not an override layer: an eval’s own timeoutMs is not overridden by the project default. Only this invocation differs—put it on the command:
This Experiment should always work this way—put it in the Experiment file:
agent, model, and flags can only be written here; no corresponding flag exists. To switch Agent or model, copy an Experiment file and change it. This keeps the target of every run in its snapshot and reproducible afterward. Shared by the whole project—put it in niceeval.config.ts:

What niceeval.config.ts can hold

See defineConfig Reference for each field’s type and full description, and CLI Reference for the complete flag table.

Environment variables: secrets and terminal facts only

The following table is every environment variable NiceEval reads. Each Agent, Sandbox, and Judge recognizes only its own names; it does not search the environment for another key. To keep a Judge key under another variable name, point to it from configuration:
When the gateway address itself is not convenient to commit, NiceEval does not need to provide an environment variable for it. Configuration is code, so read it yourself; .env has already loaded by then:
The difference is simply that the variable name belongs to your project. NiceEval does not bake in a name and then guess in the environment. Locally, put secrets in .env under the current working directory. The CLI loads it at startup without overwriting existing environment variables, so you do not need to export them every time:
.env delivers secrets; it is not a second configuration file. Writing something such as NICEEVAL_TIMEOUT there has no effect. In CI, pass secrets the same way:

Where to write the values you want to tune

Configuration has no environment-variable layer, so every item below has only one source: The Judge reads its key from NICEEVAL_JUDGE_KEY by default, or from the variable specified by judge.apiKeyEnv, and reads its endpoint only from judge.baseUrl. It never borrows the system under test’s OPENAI_API_KEY.

Continue reading

defineConfig Reference

The type and full description of every configuration field.

CLI Reference

Commands, the full flag table, and exit codes.

Write Experiments

Which values belong to one concrete run.

CI Integration

Pass secrets in CI.