Summary
jcode run --json reports "provider": "openrouter" when the session is actually running on --provider openai-compatible.
Reproduction
JCODE_OPENAI_COMPAT_API_BASE=http://127.0.0.1:8020/v1 \
OPENAI_COMPAT_API_KEY=EMPTY \
jcode run --provider openai-compatible -m <model> --json 'say ok'
Output (0.68.0):
{
"session_id": "session_jaguar_...",
"provider": "openrouter",
"model": "<model>",
"text": "\n\nok",
...
}
The request does go to the configured OpenAI-compatible endpoint — only the reported label is wrong. My guess is that the id leaks from the implementing crate, since the OpenAI-compatible runtime lives in crates/jcode-provider-openrouter-runtime/.
Why it matters
--json is the machine-readable surface, so this is the one place the label is consumed by programs rather than read by a human. Anything that aggregates runs by provider — cost attribution, per-provider success rates, routing/debugging in a harness — silently misfiles openai-compatible sessions as OpenRouter, and a run against a purely local endpoint gets attributed to a paid third-party service. It is also confusing on its own terms: nothing the user typed mentioned OpenRouter.
Expected: "provider": "openai-compatible" (or the named provider profile in use).
Environment: jcode 0.68.0, Linux x86_64.
Summary
jcode run --jsonreports"provider": "openrouter"when the session is actually running on--provider openai-compatible.Reproduction
Output (0.68.0):
{ "session_id": "session_jaguar_...", "provider": "openrouter", "model": "<model>", "text": "\n\nok", ... }The request does go to the configured OpenAI-compatible endpoint — only the reported label is wrong. My guess is that the id leaks from the implementing crate, since the OpenAI-compatible runtime lives in
crates/jcode-provider-openrouter-runtime/.Why it matters
--jsonis the machine-readable surface, so this is the one place the label is consumed by programs rather than read by a human. Anything that aggregates runs by provider — cost attribution, per-provider success rates, routing/debugging in a harness — silently misfiles openai-compatible sessions as OpenRouter, and a run against a purely local endpoint gets attributed to a paid third-party service. It is also confusing on its own terms: nothing the user typed mentioned OpenRouter.Expected:
"provider": "openai-compatible"(or the named provider profile in use).Environment: jcode 0.68.0, Linux x86_64.