Metadata inconsistencies: /props reports 0.1.6 on 0.1.7, basert-serve --version errors, /slots/{seg} echoes path as model

[kira-ariaki]

Summary

Three small inconsistencies in the server's self-reported metadata, all reproducible on the official 0.1.7 macOS arm64 bundle. Grouped into one issue since each is a one-liner; happy to split if preferred.

Environment

• BaseRT 0.1.7, official macOS arm64 release bundle
• macOS 26.4.1 (build 25E253), M1 Max 64 GB
• Model: basecompute/Qwen3-0.6B, default-q4

---

1. /props reports version 0.1.6 on a 0.1.7 build

$ basert --version
basert 0.1.7

$ curl -s http://127.0.0.1:8896/props
{..., "total_slots":1, "build":{"version":"0.1.6","target":"metal"}}

/props is the natural endpoint for a client to gate on server capabilities, so a stale version string there is misleading. Looks like the build version constant wasn't bumped with the release.

---

2. basert-serve --version is an error instead of a version

$ basert-serve --version
Unknown option: --version (see `basert serve --help`)

...followed by the full ASCII-art banner and help text. basert --version works. Since basert-serve is shipped as its own executable in the bundle, --version on it returning a version string (rather than an error + banner) would be the least surprising behaviour.

---

3. /slots/{seg} matches the literal string "0" and echoes it back as the model name

The {seg} in /slots/{seg} appears to be matched against the model id, but only the literal "0" is accepted, and it is then reflected into the model field:

$ curl -s http://127.0.0.1:8896/slots/0
[{"id":0,"model":"0","is_processing":false,"cache_tokens":0,...}]
                    ^^^ echoed path segment, not the model id

Passing the actual model id — which is what the field name suggests — fails:

$ curl -s 'http://127.0.0.1:8896/slots/basecompute/Qwen3-0.6B'
{"error":{"message":"Model not found: basecompute","type":"invalid_request_error","code":"model_not_found"}}

(The / in the model id is also split across path segments here.)

Meanwhile the collection endpoint reports the real value:

$ curl -s http://127.0.0.1:8896/slots
[{"id":0,"model":"basecompute/Qwen3-0.6B",...}]

So /slots and /slots/0 disagree on what model means. Expected: either {seg} is a slot id (and model keeps the real model id in the response), or it is a model id (and real model ids are accepted).

---

All three are cosmetic — filing mainly because #1 and #3 can mislead client code that introspects the server.