[monanklynx]

• New custom provider option with dedicated env vars (JEV_CODE_PROVIDER_NAME, JEV_CODE_BASE_URL, JEV_CODE_API_KEY, JEV_CODE_MODEL)
• Interactive setup via setup --provider custom or selecting Custom in provider menu
• Custom mode uses only its own key/base/model; ambient built-in keys are never borrowed
• Zero retries by default for custom providers; explicit JEV_CODE_MAX_RETRIES override
• Validation rejects invalid URLs, control characters, and incomplete configuration
• Doctor reports custom provider name, base URL, model, and effective retries offline
• Settings round-trip through MCP server env via serverEnvFromProcess
• Updated schema descriptions to reflect provider-model-based defaults
• Comprehensive test coverage across config, client, CLI, setup, MCP, and integrations

What

Adds a custom provider so any gateway implementing the existing System One POST /v1/systemone protocol works with jev-code, without borrowing built-in credentials or requiring a vendor
SDK.

How to verify

npm run check # lint + typecheck + tests + build + MCP smoke
npx vitest run tests/core/config.test.ts tests/cli/run.test.ts # custom-specific suites
jev-code setup --provider custom --dry-run opencode # validate prompt flow

Checklist

• npm run check passes
• Tests added or updated
• Docs updated where the contract or setup changed (README, docs/harnesses, skill references)
• CHANGELOG.md entry under Unreleased

[FrancoisChastel]

Thanks for this, @monanklynx. The goal is right: any gateway that speaks POST /v1/systemone should work with jev-code, and the spec here was careful about not leaking keys or URLs. I'm not going to merge it as is, though, because it adds a second way to configure a host where the repo already has one. I've opened #17 to carry the goal forward the way the codebase is meant to grow, and I'd value your eyes on it.

What led there:

• A System One host that isn't in the table is already the proxy case. TYPESAFE_API_KEY plus TYPESAFE_BASE_URL (and TYPESAFE_DEFAULT_MODEL when the model id differs) reach any such gateway today, and they are the variables the official SDKs read, so one export serves everything. Four new JEV_CODE_* variables duplicate those and need a custom branch through config, setup, doctor, help, serverEnvFromProcess, and the provider types. #17 documents the existing path and makes it first-class in setup instead.
• Zero retries for one kind of host gives the tool two retry defaults. If gateways need different retry behaviour, that deserves its own discussion and should apply to every host.
• The docs repeat themselves. The same section lands in four harness guides and three skill references, and the README features a third-party vendor as the example. The repo keeps the detail in the README and a line elsewhere, so the copies don't drift.
• Unrelated changes. The .gitignore additions (.specify, /specs, .agents) look like local tooling, and .npmignore has no effect because files in package.json already whitelists what gets published.
• Process, for next time. CONTRIBUTING asks for an issue before anything larger than a fix, so the approach can be agreed before 1,100 lines get written. That's on me to make clearer too.

From your spec, #17 keeps: the gateway key never borrows another host's, interactive setup asks for the URL and model, the base URL is validated before any request (absolute http(s), no credentials, query, or fragment, not ending in /v1/systemone), and a bad value is reported without being echoed. It leaves out the display name and the separate variable set.

I'll close this once #17 lands, unless you see a case the proxy path can't cover. If so, please say so there.