Greptile Summary

This PR fixes a bug where non-native openai-completions providers (custom/proxy endpoints) had supportsUsageInStreaming force-defaulted to false by normalizeModelCompat(), suppressing stream_options: { include_usage: true } in streaming requests and causing zero token-usage to be recorded for those sessions.

The fix is a single two-line change in model-compat.ts that flips the default to true, leaving the explicit opt-out (compat.supportsUsageInStreaming: false) — already used by Venice and Chutes models — fully intact. The test suite is updated to match and a new end-to-end integration test mocks globalThis.fetch to verify both that the outgoing request carries stream_options.include_usage: true and that the final usage-only SSE chunk is reflected in the recorded message usage.

Key points:

• Native api.openai.com models are not affected (the needsForce guard short-circuits before reaching the changed lines).
• Providers with an explicit compat.supportsUsageInStreaming: false (Venice, Chutes) are not affected — the hasStreamingUsageOverride guard preserves their value unchanged.
• Backward-compatibility risk: any non-native provider that rejects stream_options: { include_usage: true } will start receiving that field. The PR acknowledges this and provides an explicit opt-out, but operators of such deployments will need to set the opt-out flag manually.
• The decodeBodyText helper in the test does not handle a ReadableStream body; if pi-ai ever switches to a streaming request body the captured requestBody in the integration test would silently be empty. This is not a problem with current pi-ai behaviour but is worth noting for future maintenance.

Confidence Score: 4/5

• Safe to merge; introduces a well-guarded default change with comprehensive tests and a clear opt-out path.
• The implementation is correct and narrowly scoped. All existing explicit overrides are preserved, native OpenAI endpoints are untouched, and the new integration test validates the full request/response path. The one point of caution is that non-native providers which silently reject stream_options: { include_usage: true } will start receiving that parameter, which could surface errors in deployments that previously worked (albeit with zero usage). The explicit opt-out mechanism mitigates this, but it requires operator awareness. No security surface is changed.
• No files require special attention beyond the acknowledged backward-compatibility note about providers that reject stream_options.

_{Last reviewed commit: "fix: restore streami..."}

+1 for merging this. We're hitting this exact issue with Bailian (DashScope) providers on OpenClaw 2026.3.13.

Confirmed in production:

1. Bailian API correctly returns usage in the final SSE chunk (verified via direct curl)
2. Setting compat.supportsUsageInStreaming: true in model config has no effect because normalizeModelCompat() overwrites it to false
3. Long-running agent sessions bloat indefinitely — compaction never triggers — and eventually get force-reset, losing all conversation history

The default-to-true approach with explicit opt-out for known-broken providers is the right call. The backward-compatibility risk is minimal — providers that reject stream_options will surface a clear error rather than silently breaking compaction.

Suggestion: consider adding a log warning when stream_options.include_usage is sent but the final chunk contains no usage data — this would help users identify providers that need the explicit opt-out.

This PR + #50845 together would fully resolve the compaction failure chain for non-native providers. Would love to see both merged.

Thanks, this makes sense.

I checked the current upstream/main behavior again before changing anything else. The remaining effect of this PR is the generic default-on broadening for non-native openai-completions backends, and I agree that I do not have enough compatibility coverage to justify that blast radius yet.

Given that, I am not going to keep pushing the default wider in this PR. If it makes sense later, I can revisit this as a narrower allowlist/provider-specific change with explicit regression coverage for the known-bad paths you called out.

I've pushed a narrower follow-up on top of this PR.

What changed:

• Reverted the generic non-native default back to conservative false
• Kept auto-enable only for allowlisted endpoints with evidence in this thread / issue:
  • Scaleway AI compatible endpoints
  • DashScope compatible-mode endpoints
  • modern Azure OpenAI API versions
• Added regression coverage to keep supportsUsageInStreaming off for the known-bad paths you called out:
  • LM Studio
  • LocalAI
  • TGI
  • Ollama /v1
  • Mistral API

Validation I reran locally:

• vitest src/agents/model-compat.test.ts
• vitest src/agents/models-config.providers.modelstudio.test.ts
• targeted moonshot non-regression: opts native Moonshot baseUrls into streaming usage only after the final compat pass

If this direction looks right, I'm happy to keep iterating from here.

Closing this one to stop iterating on a stale/conflicting branch. The current branch is far behind main and still carries the older broadening direction that maintainers asked to keep conservative. If I revisit this issue, I’ll do it as a fresh, narrower PR from current main with provider/endpoint-specific coverage instead of continuing to patch this branch.