compose up: --backend flag is accepted but never applied #1036

Bug

docker model compose up defines a --backend flag (default llama.cpp) but never uses the value when calling ConfigureBackend.

Evidence (main)

In cmd/cli/commands/compose.go (newUpCommand):

var backend string
// ...
c.Flags().StringVar(&backend, "backend", llamacpp.Name, "inference backend to use")

The only write is the flag binding. backend is never read. Configure is built as:

desktopClient.ConfigureBackend(scheduling.ConfigureRequest{
    Model:                model,
    BackendConfiguration: backendConfig,
    RawRuntimeFlags:      rawRuntimeFlags,
})

There is no backend name field set from the flag. scheduling.ConfigureRequest also has no top-level backend selector (only model + BackendConfiguration + runtime flags). So even if the flag were plumbed, the request shape would need a place to put it (for example how ModelConfigEntry.Backend is stored elsewhere).

Meanwhile compose metadata advertises --backend via commandParameters(upCmd), so Compose/UI consumers may show a backend selector that does nothing.

Expected

Either:

1. Plumb --backend into the configure/install path so non-default backends work under compose, or
2. Remove the flag from up and from metadata until the API can honor it (so metadata matches behaviour).

Impact

Users (or Compose integrations) that pass --backend vllm (or anything other than the default) get silent no-ops: the flag is accepted, metadata lists it, but configuration always follows the runner default.

Related

• Compose only otherwise configures context-size / runtime-flags / speculative fields (Compose: allowlisted backend environment variables for inference process #1035 covers env separately).

I can send a PR either wiring backend selection or dropping the dead flag after maintainers pick a direction.