Summary
Two related defects discovered while adding a custom OpenAI-compatible endpoint (https://token.sensenova.cn/v1) to OpenSquilla Desktop (0.5.x). Both cause a healthy endpoint to be misreported as broken, even though real chat works fine once configured.
Problem 1: probe has a hard-coded 30s timeout → slow models reported as "unable to connect"
probe.py uses _PROBE_TIMEOUT_SECONDS = 30 with a streaming max_tokens=1 request.- The endpoint/model is actually healthy:
GET /v1/models → 200, chat completion → 200.
sensenova-6.8-flash-lite has a first-byte latency (TTFB) of ~34–70s in our measurements, so the probe always times out.- The UI "full probe" then reports "无法连接 · 30312 毫秒" (unable to connect · 30312ms), even though a normal chat (120s timeout) works perfectly.
- Suggested fix: make the probe timeout configurable, align it with the runtime request timeout, or report "slow / uncertain" instead of a hard "unable to connect" on timeout.
Problem 2: unknown models fall back to a default 8K context budget → provider_request_too_large
- When OpenSquilla does not recognize a model, it assumes a default 8K context window.
- With a system prompt + tools (~30K tokens), the request is rejected as
provider_request_too_large (ref 3ea4684e).
- Workaround that confirms the root cause — adding an explicit entry in
config.toml fixes it:
[models.custom."sensenova-6.8-flash-lite"]
context_window = 262144
max_output_tokens = 65536
- Suggested fix: for unknown models, derive the context window from
/v1/models metadata where available, or prompt the user to configure it, rather than silently using a small default.
Related
Environment
- OS: Windows 11
- OpenSquilla Desktop 0.5.x
- Endpoint: custom OpenAI-compatible (
https://token.sensenova.cn/v1)
Summary
Two related defects discovered while adding a custom OpenAI-compatible endpoint (
https://token.sensenova.cn/v1) to OpenSquilla Desktop (0.5.x). Both cause a healthy endpoint to be misreported as broken, even though real chat works fine once configured.Problem 1: probe has a hard-coded 30s timeout → slow models reported as "unable to connect"
probe.pyuses_PROBE_TIMEOUT_SECONDS = 30with a streamingmax_tokens=1request.GET /v1/models→ 200, chat completion → 200.sensenova-6.8-flash-litehas a first-byte latency (TTFB) of ~34–70s in our measurements, so the probe always times out.Problem 2: unknown models fall back to a default 8K context budget →
provider_request_too_largeprovider_request_too_large(ref3ea4684e).config.tomlfixes it:/v1/modelsmetadata where available, or prompt the user to configure it, rather than silently using a small default.Related
Environment
https://token.sensenova.cn/v1)