Skip to main content
Feature toggles flip optional or experimental behaviors for the whole installation. They live in the FeatureToggle table of the 2501 database, one row per key, and you change them there. Each time it starts, the engine writes a row for every key below that has none, keeps the state of the rows that exist, and deletes the rows of keys it no longer knows. After the first start, the table holds exactly the keys below. Operational rules and host facts are always checked before proposed task actions run when either is available. This verification has no feature toggle.

Open a database session

With the PostgreSQL 2501 deploys on Kubernetes:
On Docker Swarm, with $STACK the name you deployed the stack with (ai-2501 in Deploy):
With your own PostgreSQL, connect with the DIRECT_URL from env.engine:

List and change toggles

Command Center reads toggles on each request, so a change shows after a page reload. The engine reads them when it starts: restart it to apply a change, with kubectl -n "$NS" rollout restart deploy/engine or docker service update --force "${STACK}_engine". Turning on enableSingleSignOn or enableLogLlmInputAndOutput this way asks for no authenticator code, since database access already grants everything.

Reference

Every toggle is off on a new installation, except two the first run sets from values.yaml: enableSatelliteClusters from features.satellites, and enableElasticSearch when elasticsearch.mode is not none.

Integration

Security & Logging

Jobs

Experimental

When to flip what

  • enableElasticSearch if you have an Elasticsearch instance and want the engine + Command Center to ship logs to it.
  • enableLlmCorrelationHeaders when your LLM proxy groups requests by ticket, job or task, for example to build Langfuse sessions.
  • enableSlowInference if your tenant runs on a self-hosted model with low throughput - reduces task concurrency to avoid queue starvation.
  • enableSatelliteClusters to reach hosts from inside a customer Kubernetes cluster instead of dialing them from the engine. It adds the Clusters page and a host’s executor placement fields. Turning it back off hides that surface without changing where anything executes: a host already placed on a cluster keeps running through it, and placement stays writable through the API, so the toggle governs the surface rather than the capability.
    • While it is off, two states have no way back through the Command Center: a host cannot be returned to a direct dial, and a credential held by a cluster cannot be deleted. Turn the toggle on to unwind either.
  • Anything labeled experimental: open a support ticket before enabling in production.