aliases / specify model+reasoning combinations once / local XDG settings not read

[rxgrant]

Because different contributors to open source projects have different model credentials and different (possibly local) capabilities, the project's model settings, including reasoning.effort, must be overridden locally. Model aliases provide some but not all of this functionality.

It is possible to specify anything on the command line, but local config files should handle this.

Does config_load_paths operate in XDG/config.toml? Does setting it allow mirroring the project persona hierarchy with XDG persona patches, so that -c dev loads from the project dev.toml persona as well as the XDG-path dev.toml persona? It seems not. This does not seem like a favorable solution in any case, as locally mirroring the project personas sounds fragile.

I think JP's current theory would like me to use a local-to-machine-and-project config.toml. However, model availability comes and goes frequently, and I want to name model+reasoning combinations once, not duplicate this configuration task around in dozens of different project files, with some always out of date.

[JeanMertz]

funnily enough, I had a similar thought two days ago where I was thinking about moving aliases "up one level", so instead of aliasing just the model name, you could alias the entire model configuration.

I didn't pursue it at the time both to stay focused at the task at hand, but also because I thought it wasn't needed, since our config system makes it easy to create your own "alias" files using e.g. jp q -c alias/my-model-with-custom-config.

But let me dig into this question some more now and see if my assumption is correct, or if there are edge-cases that won't work, such as the one you describe.

I want to name model+reasoning combinations once, not duplicate this configuration task around in dozens of different project files, with some always out of date.

Is this you saying what I said above works, but the pain point is in having to define multiple different files such as alias/my-model-1.toml and alias/my-model-2.toml instead of having one aliases.toml with all the different alias + model configs defined inline in that single file?

[JeanMertz]

To get more specific on your point(s), I read them as three separate issues you raise, but correct me if I am wrong:

1. Local model overrides
2. Name a model+reasoning combination once.
3. XDG / config_load_paths exact workings.

points 1 and 3:

For config_load_path, see https://jp.computer/rfd/035-multi-root-config-load-path-resolution, which is implemented and details how config load paths across the three different roots (workspace, user-workspace, user-global) works.

A single -c dev searches the user-global root, workspace root, and user-workspace root, and merges every match in precedence order. So a personal config/personas/dev.toml in your XDG dir does patch the project's dev.toml.

For example, here is an example of how I "patch" the web search skill to include Kagi-specific tools (that are behind a paid API, which is why they aren't part of JP's shared tool set):

cat ~/Library/Application\ Support/jp/config/.jp/config/skill/web.toml

[[assistant.system_prompt_sections]]
tag = "web_skill"
title = "Skill: Web Acccess"
content = """\
Your web-access skill also gives you the capability to search using the Kagi search engine, and \
ask Kagi to summarize web pages for you.

The following tools help you with this:

- web_search: Search the web for a query.
- web_summarize_content: Summarize the contents of a web page.
"""

[conversation.tools]
web_search = { enable = true, run = "unattended", result = "unattended", style.inline_results = "off", style.results_file_link = "off" }
web_summarize_content = { enable = true, run = "unattended", result = "unattended", style.inline_results = "off", style.results_file_link = "off" }

point 2:

This is what I mentioned above. I've thought about it, but haven't designed or implemented it since I didn't see a direct need given the flexibility of the config system. If your concern is the "I don't want to maintain multiple files to do jp -c alias/{a,b,c}", then that is a valid one, but I believe it should be designed differently from combining model+reasoning into a single alias.

Instead, it might be worth looking at allowing -c to not just reference config files, but config blocks in a single file. For example, a file such as:

# alias.toml

[config.a.assistant.model]
id = "..."
reasoning = "..."

[config.b.assistant.model]
id = "..."
reasoning = "..."

Then, when doing jp -c alias/a we don't just look for a file alias/a.toml, but also for a file alias.toml which has a config.a segment defined.

This is just spitballing some design ideas, so I'd have to investigate and weigh the pro's and con's, but this would be more flexible without expanding the model alias.

The reason I would push for a more generic solution is that, while I think model aliases are worthwhile to have as they are, expanding them in scope creeps up on a config-design-degradation I've been catching myself running into frequently and having to back out of, which is that I sometimes want to add a new config field that is a map of named field collections, e.g. say conversation.templates.foo = { ... } and conversation.templates.bar = { ... }, only to realize this would re-model the existing config-file load system into the actual config-structure, in other words the above could easily be written today as foo.toml: conversation.template = { ... }andbar.toml: conversation.template = { ... }and then usingjp -c {foo,bar}`.

But I do see how the "forced to split this over 2 or more files" can be annoying, which is why I think a global "config blocks" in a single file could be the right trade-off here, essentially doing the "re-model the existing config-file load system into the actual config-structure" ONCE at the root-level using config.<name>.<app-config>, which then allows for all config set-ups to be grouped into a single file, if desired, without special casing model aliases, conversation.templates, etc.

[JeanMertz]

Thinking on this some more, I believe extends already gives you config bundles in files, today. This does not negate the potential usefulness of config.<name> blocks to group files, but if you define a models/opus-high.toml with [assistant.model] + [...parameters.reasoning], pulled in via extends = ["models/opus-high.toml"] from, e.g., your user-workspace base config.toml file, you would be able to define your models that way.

As I said, if your issue with that is the multiple-files requirement, then the config.<name> idea seems to solve that problem?

[rxgrant]

merges every match in precedence order

I tried this but could not get this to work and received no feedback why it wasn't working (jp v0.1.0-627020d1 (2026-06-02)).

[rxgrant]

config blocks

That sounds too complicated. I already cannot model in mind what the config system is doing.