Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Environment:

• OpenClaw 2026.4.14 (323493f)
• macOS / Homebrew install
• OpenRouter provider plugin loaded
• OpenRouter auth valid and paid credit present

Problem:
When OpenRouter text-inference models are used through the OpenClaw cron-agent-turn harness, the run returns:

• stopReason: "stop"
• content: []
• usage: {input:0, output:0, cost:0}
• no fallback triggered
• downstream generic error: "Agent couldn't generate a response"

This reproduces across:

• openrouter/meta-llama/llama-3.1-8b-instruct
• openrouter/openai/gpt-oss-120b:free
• openrouter/meta-llama/llama-3.3-70b-instruct

All three succeed with the same token and same prompt when called directly via OpenRouter /v1/chat/completions.

Observed common factor:

• failing OpenClaw path records modelApi: "openai-completions" for provider openrouter

Expected:

• either a real non-empty assistant response
• or a surfaced provider error that allows fallback

Actual:

• silent empty "success" with zero usage and no fallback

Not likely to be:

• model-choice issue
• context-window issue
• pricing-tier issue
• auth issue

Evidence artifact:
/OPENCLAW_2026_4_14_OPENROUTER_HARNESS_EMPTY_RESPONSE.md

Evidence sessions:

• /19e9fe36-a5a7-4902-9b7e-cc048537c589.jsonl
• /7750a260-c526-4cb0-b3a6-fc93bb9e4e94.jsonl
• /be129d6a-e9dc-438f-92cb-0faebe9714d2.jsonl
• /c214cbc5-fcff-4637-9d6d-88c02bca061d.jsonl

Question:
Is openai-completions -> openrouter expected to work in 2026.4.14, or does OpenRouter require a different modelApi / request shape in this build?

Steps to reproduce

1. On OpenClaw 2026.4.14, register an OpenRouter text model in ~/.openclaw/openclaw.json under agents.defaults.models, for example:
   "openrouter/meta-llama/llama-3.3-70b-instruct": { "alias": "CHEAP" }

2. Validate config and confirm the model is registered:

   • openclaw config validate
   • openclaw models list
     Expected: CHEAP resolves to the OpenRouter model and is not marked missing.

3. Create a disabled throwaway cron job using the same real heartbeat-style workload shape:

   • model: CHEAP
   • light-context: true
   • session: isolated
   • no-deliver: true
   • disabled: true
   • prompt: the same heartbeat/status prompt used by the existing daily cron

4. Trigger the cron job once manually:

   • openclaw cron run --expect-final --timeout 150000

5. Inspect the run result and its session transcript in .

Observed result:

• run ends in generic "Agent couldn't generate a response"
• session shows provider=openrouter, modelApi="openai-completions"
• assistant reply has:
  • stopReason: "stop"
  • content: []
  • usage: { input: 0, output: 0, cost: 0 }
• no fallback triggers

Control observation:

• the same token + same prompt + same model succeeds via direct HTTPS to OpenRouter /v1/chat/completions with non-empty structured output.

Expected behavior

When an OpenRouter text-inference model is invoked via the OpenClaw cron-agent-turn harness, the model should return a non-empty assistant response consistent with the provided prompt, OR return a surfaced provider error that triggers the configured fallback chain.

Grounded reference:

• The same token, model, and prompt produce a valid structured response when sent directly to OpenRouter via /v1/chat/completions.
• Non-OpenRouter providers (e.g. openai/gpt-4o-mini) correctly surface upstream errors (e.g. rate_limit) and trigger fallback behavior inside the OpenClaw harness.

Therefore, expected behavior is:

• Either valid non-empty content from OpenRouter
• Or explicit error propagation enabling fallback

Actual behavior

When invoked through the OpenClaw cron-agent-turn harness, OpenRouter models return a silent empty response:

• stopReason: "stop"
• content: []
• usage: { input: 0, output: 0, cost: 0 }
• no fallback triggered
• downstream error: "Agent couldn't generate a response"

This occurs consistently across multiple OpenRouter models:

• openrouter/meta-llama/llama-3.1-8b-instruct
• openrouter/openai/gpt-oss-120b:free
• openrouter/meta-llama/llama-3.3-70b-instruct

Session evidence confirms:

• modelApi: "openai-completions"
• provider: "openrouter"
• empty assistant content with no error surfaced

Control test:

• Direct HTTPS call to OpenRouter /v1/chat/completions with the same token and prompt returns valid structured output.

Conclusion:

• OpenClaw harness incorrectly interprets or constructs the OpenRouter request/response, resulting in silent empty completions.

OpenClaw version

2026.4.14 (323493f)

Operating system

macOS 15.x (Darwin 25.3.0)

Install method

Homebrew global install

Model

openrouter/meta-llama/llama-3.3-70b-instruct

Provider / routing chain

openclaw -> openrouter (modelApi: openai-completions) -> upstream providers (DeepInfra / OpenInference / Nebius)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response