Error: "model ID config must match <provider>/<model>"

[parasyte]

Added openai as a provider alias, and jp returns this error:

% cat ~/.config/jp/config.toml
[user]
name = "jay"

[providers.llm.aliases]
#opus = "anthropic/claude-opus-4-7"
#sonnet = "anthropic/claude-sonnet-4-6"
#gemini = "google/gemini-3.1-pro-preview"
cerebras = "cerebras/zai-glm-4.7"
openai = "openai/gpt-5.5"

% jp q -n -c dev -m openai hello
Config error

    conversation.inquiry.assistant.model.id: model ID config must match <provider>/<model>

Full trace log written to: /tmp/.tmpOMC61X

The log in /tmp doesn't seem to have anything useful. It's too big to post directly to GitHub.

---

Same error occurs with model alias cerebras.

I get a slightly different error when I rename my config.toml:

% mv ~/.config/jp/config.toml ~/.config/jp/config.toml.do-not-use

% jp q -n -c dev -m cerebras hello
Config error

    assistant.model.id: model ID config must match <provider>/<model>

Full trace log written to: /tmp/.tmphEif7F

[parasyte]

Did some troubleshooting and found the cause was that the repo jp config contained:

[conversation.inquiry.assistant.model]
id = "sonnet"

[conversation.title.generate.model]
id = "sonnet"

With sonnet commented out of my environment config, this unhelpful error was appearing. (I don't have an API key for Anthropic.)

Fixed by changing the id fields to a provider that I do have an API key for.

[rxgrant]

I was able to reproduce this bug by undefining all anthropic models from my [providers.llm.aliases] in my local config, causing the same output.

The culprit was a "sonnet" LLM in the project .jp/config.toml. Since not all users may
have all API keys defined, I moved all LLM aliases into the local configs.

The fix, in project config.toml, is to generalize which llm is doing summaries:

[conversation.inquiry.assistant.model]
id = "summarizer"
parameters.reasoning.effort = "auto"

[conversation.title.generate.model]
id = "summarizer"
parameters.reasoning.effort = "low"

Then users can set this to what makes sense for them.

[rxgrant]

I would say this error string needs a lot of love, since with different LLM API keys floating around, this will happen a lot.

[JeanMertz]

Thanks for the report.

A few things that are relevant:

1. First, yes, errors need a LOT of love. I haven't spent a lot of time on them yet, it hasn't been a priority, but with N>1 users, it has to become a priority.
2. The bad error when an alias is undefined is definitely something we can and should already fix though
3. As for the current workspace config, it is a mix of truly workspace config and my own config preferences that has bled into the workspace since I was the only one using the tool here, so I never encountered really any "this might be useful for me, but perhaps not for others" while configuring JP in this workspace, it does now though, so we'll have to find a consensus on what goes in the workspace and what goes in our local configs.
4. I agree with. @rxgrant that we should define a few generic aliases in the workspace, that can be either best and cheap or something, or we use model aliases specific to their purposes (main, summarizer, title, etc).

I'll start with fixing (2), and then move on to (3) and (4). (1) needs an RFD that can follow later.

If you find any other issues. DO report them to me, the N>1 case is super useful and only now are we seeing where my biases as a sole developer and user does not match the broader consensus.

FYI: I just created #653 for whenever you run into something minor that you want to report, without having the time to write up a full bug report. Any report in there, even if it's just one sentence, can help us improve JP's UX.

[JeanMertz]

A quick fix is in #654. A more permanent fix should be to not overload model.id for three different formats:

• model.id = "my alias"
• model.id = "openai/gpt"
• model.id = { provider = "openai", name = "gpt" }

Those last two are fine to keep together, but I think we should move alias to its own model.alias field (mutually exclusive with id), which would then allow us to provide more accurate error messages and allows us to print a full list of known model aliases whenever we find a reference to an unknown alias.