[Bug]: LiteLLM non-task helpers call undefined/chat/completions

[tomny-dev]

Preflight

• I searched existing issues and docs before opening this.
• I removed secrets, tokens, private keys, customer data, and private repository details from logs and screenshots.
• This report describes observed behavior, not a speculative AI-generated rewrite request.

Summary

When a self-hosted Roomote deployment uses a LiteLLM-backed model for non-task helper inference, GitHub mention routing fails because the restricted OpenCode runtime selects the model ID but does not appear to register the endpoint-backed provider configuration.

The request reaches the GitHub webhook successfully, but the control-plane inference call attempts to use an invalid URL:

undefined/chat/completions

Normal task conversations are unaffected because the worker runtime appears to generate the complete endpoint-provider configuration.

Affected surface

API

Steps to reproduce

1. Deploy Roomote using the official Docker Compose/Coolify setup.

2. Configure a LiteLLM provider with a valid base URL and API key.

3. Select a LiteLLM model for both the coding model and small/helper model, for example:

   litellm/qwen3.6:35b-unsloth
   

4. Install the Roomote GitHub App on a repository.

5. Comment on a pull request:

   @<roomote-app-slug> review this PR
   

6. Observe the API logs.

Expected behavior

Roomote should use the configured LiteLLM endpoint for the non-task helper call, route the GitHub request, and enqueue the review task.

Actual behavior

The webhook reaches Roomote, but structured helper inference fails before routing or task enqueueing:

OpenCode structured prompt failed: UnknownError: "undefined/chat/completions" cannot be parsed as a URL.

Supplying only options.baseURL changes the failure to a generic server error, suggesting that the provider adapter and model catalog are also required.

As a deployment workaround, setting OPENCODE_CONFIG_CONTENT with a complete OpenAI-compatible provider entry makes the same GitHub mention route successfully. The working shape includes:

• npm: "@ai-sdk/openai-compatible"
• the LiteLLM provider name
• options.baseURL
• an API-key environment reference
• a model catalog entry for the selected helper model

After applying that workaround, the logs show a successful direct routing decision and environment resolution:

[LLM Router] Routed GitHub task ... followUpMode="review" ...
[enqueueTask] Auto-resolved environment ...

Roomote version

ghcr.io/roocodeinc/roomote-app:develop

Installation method

Docker Compose

Deployment context

Host OS / architecture: Linux, amd64
Deployment: Docker Compose managed by Coolify
Postgres: Official Roomote Compose service
Redis: Official Roomote Compose service
Object storage: Official Roomote Compose service
Public URL / reverse proxy: Cloudflare Tunnel in front of Coolify/Traefik
Compute provider: Docker
Model gateway: Self-hosted LiteLLM exposing an OpenAI-compatible /v1 endpoint

Diagnostics output

No response

Logs, screenshots, task IDs, or job IDs

OpenCode structured prompt failed: UnknownError: "undefined/chat/completions" cannot be parsed as a URL.

Additional context

The issue appears limited to restricted non-task OpenCode helpers such as GitHub routing and other control-plane inference. The task worker path already appears to construct endpoint-backed provider metadata correctly.

Temporary workaround

Setting OPENCODE_CONFIG_CONTENT on the API service with a complete OpenAI-compatible provider entry makes the same GitHub mention route successfully.

A sanitized version of the working override is:

services:
  api:
    environment:
      LITELLM_API_KEY: ${LITELLM_API_KEY}
      LITELLM_BASE_URL: http://<litellm-host>:4000/v1
      OPENCODE_CONFIG_CONTENT: >-
        {"model":"litellm/qwen3.6:35b-unsloth","small_model":"litellm/qwen3.6:35b-unsloth","provider":{"litellm":{"npm":"@ai-sdk/openai-compatible","name":"LiteLLM","options":{"baseURL":"http://<litellm-host>:4000/v1","apiKey":"{env:LITELLM_API_KEY}"},"models":{"qwen3.6:35b-unsloth":{"name":"qwen3.6:35b-unsloth"}}}}}

The deployment still provides LITELLM_API_KEY separately; the secret is not embedded in the JSON.

Adding only options.baseURL was not sufficient. The provider adapter and model catalog were also required.

After applying the full override, the logs show a successful direct routing decision and environment resolution:

[LLM Router] Routed GitHub task ... followUpMode="review" ...
[enqueueTask] Auto-resolved environment ...

[roomote-roomote]

I've analyzed this issue and here's my proposed implementation plan:

1. Extract the OpenAI-compatible provider config builder currently local to apps/worker/src/run-task/agent-home.ts into a pure, shared @roomote/types utility. Keep the existing behavior for LiteLLM, Ollama, vLLM, the default openai-compatible provider, and named openai-compatible-<slug> connections: adapter package, provider name, resolved baseURL, environment-referenced API key, and model catalog entries.
2. Update apps/worker/src/run-task/agent-home.ts to consume that shared builder so normal task configuration remains unchanged and there is one source of truth for endpoint-backed providers.
3. Update packages/cloud-agents/src/server/opencode-runtime.ts to apply the same shared provider builder when constructing restricted non-task OPENCODE_CONFIG_CONTENT. Feed it the effective runtime environment and selected coding/helper model IDs before the existing restriction pass; provider is already allowlisted while tool, MCP, plugin, and agent configuration remains stripped.
4. Add focused unit coverage in packages/types for provider materialization and in packages/cloud-agents/src/server/__tests__/opencode-runtime.test.ts for a LiteLLM helper model. Assert the restricted config contains npm: "@ai-sdk/openai-compatible", the configured base URL, an {env:LITELLM_API_KEY} reference, and the selected model entry, while retaining all non-task permission denials. Retain the existing worker tests as regression coverage for task execution and named OpenAI-compatible connections.
5. Run the targeted @roomote/types, @roomote/cloud-agents, and worker config tests plus package type checks. No schema, API contract, or documentation change should be needed.

The root cause is that resolveEffectiveModelRuntimeEnv() already returns the LiteLLM endpoint and credential environment, but the non-task builder currently turns only R_MODEL / R_SMALL_MODEL and reasoning settings into OpenCode config. The worker independently materializes the complete endpoint-backed provider block. Sharing that builder gives restricted helpers the required provider registration without weakening their tool sandbox or requiring an operator-supplied OPENCODE_CONFIG_CONTENT workaround.

Please tag @roomote if you'd like me to implement this, or reply with feedback on the plan.

[tomny-dev]

@roomote please give it a shot!

[roomote-roomote]

I saw the mention, but I need your GitHub account linked to Roomote before issue and PR comments can start work here. Link it from Settings -> Linked Accounts and then mention me again.

[mrubens]

@roomote listen to him! @tomny-dev we’re working on a way to make roomote listen to you, stay tuned!

[roomote-roomote]

I'm on it. I started a task for this issue, and I'll keep updates here.

See task

[roomote-roomote]

Implemented the LiteLLM non-task helper fix in draft PR #964: #964

Restricted helpers now receive the same OpenAI-compatible provider metadata as task workers, including the adapter, endpoint, env-key reference, model catalog, and implicit litellm/ prefixing. Targeted regression tests, package type checks, and the repository pre-push checks pass.