Version: 0.42.56.0, Postgres engine. chat_model = openai:gpt-4o-mini (confirmed via gbrain config get chat_model), OPENAI_API_KEY exported in the shell.
Observed:
gbrain enrich --thin --types person --limit 3 --max-usd 0.25 → exits with Chat gateway unavailable. Configure a chat model…gbrain enrich … --dry-run → works (14 candidates enumerated).gbrain enrich … --background + gbrain jobs work → all jobs complete successfully with the same env/config.- Passing
--model openai:gpt-4o-mini explicitly does not change the direct-path failure.
Cause (from reading the source): the gate at src/commands/enrich.ts (if (!parsed.dryRun && !isAvailable('chat'))) runs before the engine/gateway is configured. isAvailable (src/core/ai/gateway.ts) returns false whenever _config is null — configureGateway() hasn't been called yet at that point in the direct CLI path — so the check reports "unavailable" regardless of actual config/keys. The jobs worker configures the engine before executing the handler, which is why --background succeeds.
Suggestion: move the availability gate after engine/gateway initialization (or call configureGateway from resolved config + process.env before the gate). The current error message sends users chasing model/key config that is actually fine.
Version: 0.42.56.0, Postgres engine.
chat_model = openai:gpt-4o-mini(confirmed viagbrain config get chat_model),OPENAI_API_KEYexported in the shell.Observed:
gbrain enrich --thin --types person --limit 3 --max-usd 0.25→ exits withChat gateway unavailable. Configure a chat model…gbrain enrich … --dry-run→ works (14 candidates enumerated).gbrain enrich … --background+gbrain jobs work→ all jobs complete successfully with the same env/config.--model openai:gpt-4o-miniexplicitly does not change the direct-path failure.Cause (from reading the source): the gate at src/commands/enrich.ts (
if (!parsed.dryRun && !isAvailable('chat'))) runs before the engine/gateway is configured.isAvailable(src/core/ai/gateway.ts) returnsfalsewhenever_configis null —configureGateway()hasn't been called yet at that point in the direct CLI path — so the check reports "unavailable" regardless of actual config/keys. The jobs worker configures the engine before executing the handler, which is why--backgroundsucceeds.Suggestion: move the availability gate after engine/gateway initialization (or call
configureGatewayfrom resolved config + process.env before the gate). The current error message sends users chasing model/key config that is actually fine.