Skip to content

init silently writes broken vLLM config when detection finds non-vLLM provider #1

Description

@rendrag-git

Bug

oc-bench init --providers local (without --no-detect) runs the detection cascade and picks the first candidate, but init_quickstart only knows how to construct a VllmEndpoint. When the cascade returns Ollama / llama.cpp / LM Studio (whose generators are detect-only stubs), init silently falls back to default vLLM values (http://127.0.0.1:8000/v1 + gpt-oss-20b-nvfp4-smoke) and writes a config pointing at a port nothing is listening on.

Reproduction

On any machine running Ollama (`*:11434` listening) without a vLLM on loopback:

```bash
python3 -m openclaw_bench init --providers local --bench-root /tmp/x --openclaw-profile demo --gateway-port 19299 --no-validate
```

Result: exit 0, generated config has `baseUrl=http://127.0.0.1:8000/v1\`, `models[0].id=gpt-oss-20b-nvfp4-smoke` — both pointing at nothing. User believes init worked.

Expected

One of:

  • Error loudly: `detected but config generation for it isn't yet implemented; pass --no-detect with --vllm-* flags or wait for the generator follow-up`.
  • Or: only run detection for providers whose generators exist (currently only vllm), and treat detect-only stubs as "not findable" from `init`'s perspective.

Where

`openclaw_bench/cli.py` `init_command` — the candidate-selection `next((c for c in report.candidates if c.provider == "vllm"), report.candidates[0])` falls through to a non-vLLM candidate, then `init_quickstart` ignores it via the `if detected_candidate.provider == "vllm"` gate in `openclaw_bench/quickstart.py`.

Severity

P1 — the deployment-surface command silently produces a broken artifact. New-user UX is the explicit M3 goal.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions