Summary

Describe the problem and fix in 2–5 bullets:

• Problem: AIPing LLM provider was not integrated. Documentation/examples used test-key instead of a generic api-key, and AIPing's router-param feature was not exposed to users.
• Why it matters: Enables users to leverage AIPing's OpenAI-compatible LLM services and its advanced routing capabilities within OpenClaw, improving flexibility and choice. Clarifies documentation for better user experience.
• What changed:
  • Added AIPing as a new OpenAI-compatible LLM provider with default base URL https://aiping.cn/api/v1.
  • Integrated AIPing into the onboarding, auth-choice, and credential storage flows, including AIPING_API_KEY environment variable support.
  • Updated AIPing-related test examples to use a more generic aiping-api-key placeholder.
  • Added documentation for AIPing's router-param feature, showing how to use it via model name colon syntax (e.g., aiping/model:latency).
• What did NOT change (scope boundary): Core LLM interaction logic for existing providers; test-key usage in non-AIPing specific tests.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #

User-visible / Behavior Changes

• New LLM provider "AIPing" is now available.
• Users can authenticate with AIPing via --auth-choice aiping-api-key or --aiping-api-key <key>.
• AIPing's router-param feature can be used by appending colon-separated parameters to the model name (e.g., aiping/DeepSeek-R1:latency).
• New documentation page for AIPing provider.

Security Impact (required)

• New permissions/capabilities? (Yes) - New provider integration allows calls to AIPing API.
• Secrets/tokens handling changed? (Yes) - Added handling for AIPING_API_KEY.
• New/changed network calls? (Yes) - New network calls to https://aiping.cn/api/v1.
• Command/tool execution surface changed? (Yes) - New CLI flags for AIPing authentication.
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:
  • Risk: Exposure of AIPing API key if not handled securely.
  • Mitigation: API key is stored and handled using existing secure credential management practices (environment variables, encrypted auth profiles). Network calls are made over HTTPS.

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node.js (pnpm)
• Model/provider: AIPing
• Integration/channel (if any): OpenClaw CLI
• Relevant config (redacted):

  export AIPING_API_KEY="QC-..."

Steps

1. Set AIPING_API_KEY environment variable.
2. Run openclaw models list to see aiping models.
3. Run openclaw models set aiping/DeepSeek-V3.2.
4. Run openclaw chat "Hello, AIPing!".
5. Test router-param: openclaw models set "aiping/DeepSeek-R1:latency".
6. Run openclaw chat "Test router param.".

Expected

• AIPing models are listed and selectable.
• Chat interactions with AIPing models work correctly.
• Router-param syntax is accepted and presumably applied by the AIPing endpoint.

Actual

• Verified as expected.

Evidence

• Failing test/log before + passing after (focused tests for onboarding/auth/provider flows)
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • AIPing provider registration and model listing.
  • Interactive and non-interactive authentication with AIPING_API_KEY.
  • Chat completion using AIPing models.
  • router-param syntax in openclaw models set.
  • Documentation updates for AIPing provider and router-param.
• Edge cases checked:
  • Missing AIPING_API_KEY (falls back to interactive onboarding).
• What you did not verify:
  • The actual effect of router-param on AIPing's backend routing logic (assumed correct based on AIPing API docs).

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (Yes) - New AIPING_API_KEY environment variable.
• Migration needed? (No)
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: Revert the PR.
• Files/config to restore: None, as this is an additive change.
• Known bad symptoms reviewers should watch for:
  • AIPing models not appearing in openclaw models list.
  • Authentication failures when AIPING_API_KEY is set.
  • Incorrect or missing AIPing documentation.

Risks and Mitigations

• Risk: New external dependency on AIPing API.
  • Mitigation: Standard API key authentication and HTTPS communication are used. No custom or complex integration logic that could introduce new vulnerabilities.
• Risk: Potential for router-param syntax conflicts with other providers or future OpenClaw features.
  • Mitigation: The colon syntax is specific to AIPing's model parsing and is documented. It's unlikely to conflict with other providers that don't explicitly support it.