#20962: Fix/context window size for custom api provider

## Summary - **Problem:** Custom API providers defaulted to a 4096-token context window, which is below the agent's minimum requirement of 16000 tokens, causing immediate failure: `Model context window too small (4096 tokens). Minimum is 16000.` - **Why it matters:** Users onboarding custom providers (e.g., Ollama, self-hosted endpoints) could not use the agent at all without manually editing config after onboarding. - **What changed:** Raised `DEFAULT_CONTEXT_WINDOW` from 4096 to 16000. Added `--custom-context-window` and `--custom-max-tokens` CLI flags to allow specifying the model's actual capabilities. Added validation (context window >= 16000, max tokens >= 1000, must be integers). - **What did NOT change (scope boundary):** Interactive wizard flow (still uses defaults), existing provider configs, gateway/orchestration logic, context window guard itself. ## Change Type (select all) - [x] Bug fix - [x] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [x] API / contracts - [x] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes # - Related # ## User-visible / Behavior Changes - `DEFAULT_CONTEXT_WINDOW` for custom providers changed from `4096` to `16000`. Re-onboarding picks up the new default. - New optional CLI flags: `--custom-context-window <size>` (default 16000, min 16000) and `--custom-max-tokens <size>` (default 4096, min 1000). - Invalid values (non-integer, below minimum) produce a clear error message and exit. ## Security Impact (required) - New permissions/capabilities? `No` - Secrets/tokens handling changed? `No` - New/changed network calls? `No` - Command/tool execution surface changed? `No` - Data access scope changed? `No` ## Repro + Verification ### Environment - OS: macOS Darwin 24.6.0 - Runtime/container: Node.js (pnpm dev) - Model/provider: Any custom OpenAI-compatible provider - Integration/channel: CLI onboard wizard - Relevant config: `openclaw onboard --non-interactive --auth-choice custom-api-key` ### Steps 1. `pnpm openclaw onboard --non-interactive --accept-risk --auth-choice custom-api-key --custom-base-url http://127.0.0.1:11434/v1 --custom-model-id llama3` 2. Observe the generated config's context window value. 3. Repeat with `--custom-context-window 32000 --custom-max-tokens 8192` and verify values. 4. Repeat with `--custom-context-window 8000` and verify validation error. ### Expected - Step 1: config has `contextWindow: 16000`, `maxTokens: 4096`; agent starts successfully. - Step 3: config has `contextWindow: 32000`, `maxTokens: 8192`. - Step 4: error: `Custom context window must be an integer >= 16000.` ### Actual - no support for custom params for context-window or max-tokens ## Evidence - [x] Failing test/log before + passing after - `pnpm test:e2e src/commands/onboard-custom.e2e.test.ts` — 18/18 tests pass (6 new tests covering custom values, defaults, minimum enforcement, and non-integer rejection) ## Human Verification (required) - **Verified scenarios:** All 18 e2e tests pass; type check (`pnpm tsgo --noEmit`) clean. - **Edge cases checked:** Non-integer values (16000.5, 1000.7), below-minimum values (8000, 500), omitted values (defaults applied). - **What you did not verify:** Full interactive wizard flow end-to-end with a live Ollama instance; existing configs are not migrated (re-onboard required to pick up new default). ## Compatibility / Migration - Backward compatible? `Yes` — new flags are optional; existing configs are untouched. - Config/env changes? `Yes` — new default context window is 16000 instead of 4096 for newly onboarded custom providers only. - Migration needed? `No` — existing users can re-run onboard or manually edit their config. ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: Revert the 4 changed files; the only functional constant change is `DEFAULT_CONTEXT_WINDOW` 4096→16000. - Files/config to restore: `src/commands/onboard-custom.ts`, `src/commands/onboard-types.ts`, `src/cli/program/register.onboard.ts`, `src/commands/onboard-non-interactive/local/auth-choice.ts` - Known bad symptoms: If validation thresholds are too strict for a niche model, user will see a clear error message and can omit the flag to use defaults. ## Risks and Mitigations - **Risk:** Users with existing custom provider configs still have `contextWindow: 4096` and must re-onboard to fix. - **Mitigation:** This is expected — can't mutate existing configs. The error message from the agent already tells users the minimum is 16000, guiding them to re-onboard. <!-- greptile_comment --> <h3>Greptile Summary</h3> raised default context window from 4096 to 16000 tokens to match agent minimum requirements, and added `--custom-context-window` and `--custom-max-tokens` CLI flags with validation (context window >= 16000, max tokens >= 1000, must be integers). **Major changes:** - `DEFAULT_CONTEXT_WINDOW` changed from 4096 to 16000 in `onboard-custom.ts:12` - added optional CLI flags for custom context window and max tokens in `register.onboard.ts:93-97` - added validation for both parameters with clear error messages in `onboard-custom.ts:487-503` - added 6 new e2e tests covering defaults, custom values, minimum enforcement, and non-integer rejection **Issue found:** - when re-onboarding an existing model with new context window or max tokens values, the changes are silently ignored because `mergedModels` uses the unmodified `existingModels` array when `hasModel` is true (`onboard-custom.ts:541`) <h3>Confidence Score: 3/5</h3> - safe to merge with one logical bug that affects re-onboarding scenarios - the PR correctly implements the default change and validation logic with good test coverage. however, there's a bug where re-onboarding an existing model with new context window or max tokens values silently ignores the changes. this affects the stated use case of "users could not use the agent at all without manually editing config after onboarding" - if they try to fix it by re-running onboard with flags, it won't work for existing models - `src/commands/onboard-custom.ts` - fix the model update logic on line 541 to handle re-onboarding with new values _{Last reviewed commit: d51ab23} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->