Repository navigation
Determinaticly associate agenst and variants to commands #560
Description
To upvote this issue, give it a thumbs up. See this list for the most upvoted issues.
Related to #474 , thinking about it what I would like is to have a command be run with a specific model and a specific variant; for example when calling /compact I want to use a model that is fast at ingestion , if I create a /commit command I want a small and fast model, etc.
Adding model: and variant: at the comments in the markdown files would be nice.
Activity
ericdallo commentedon Aug 3, 2026
Interesting, I believe we can support that in our custom commands, md metadata and in our config.
WDYT @zikajk ?
zikajk commentedon Aug 3, 2026
@ericdallo I don't think it's worth adding the code. Personally, this is exactly what I do—I have a command where I specify
Another option, of course, is having a sub-agent for git operations, etc. which is in my opinion the standard way how to do stuff like this.
The only thing where it might make sense is /compact (via config), which is specific. Though that's probably a niche use case, since it ends up being more expensive than hitting the cache with the current model.
Btw. If you remember, a while ago we discussed that skills will replace commands. Or rather, existing commands will stay, but skills will get new metadata that determines whether they can be called only by the user, by the model as well, etc. So I wouldn't add metadata to the existing commands.
ericdallo commentedon Aug 3, 2026
well rememebered, I believe swap to skills which already support this is the best, the only missing thing is for compact tool which might make sense to support config to change its model/variant, but agree with the rest
zikajk commentedon Aug 3, 2026
@apalazzi Is there a reason why don't you create a
/commitcommand with a prompt like:apalazzi commentedon Aug 3, 2026
The reason is that I prefer deterministic behavior over leaving it to a LLM if possible: although generally it would probably work, there could be times where the LLM misspell the subagent or decides not to use it at all, making it deterministic guarantees the expected result. In your case you should instruct every agent to use that subagent. And if you think of using shills, then make it so that skills can be activated in a deterministic way: simply telling the agent to load them in AGENTS.md doesn't work for me.
Moreover it seems clearer to me to add a couple of lines at the header of the md file or in the config file where the command is defined.
zikajk commentedon Aug 3, 2026
I get it. Personally, I think skills and commands should always represent a prompt and we should be consistent about it (though in some harnesses, 'skills' even experimentally control available tools). If you want it deterministic, you could make a sub-agent for it. But honestly, I think nowadays you won't even come across a model that wouldn't respect that.
"The 'compact' option is a different story, but are you sure you want to pay for the entire conversation instead of utilizing the cache?
zikajk commentedon Aug 3, 2026
Btw. you can call skill in a deterministic way as
/skillbut adding something likeagentto the skill metadata doesn't make really sense because it would then call a subagent in ECA but work like a normal skill everywhere else. And it would be strange even in ECA if you think about it.apalazzi commentedon Aug 3, 2026
@zikajk I'm sorry, maybe I'm misunderstanding, but:
Regarding compact: on my local AI system there are agents who achieve 1k pp and other that barely reach 50 and even lower token generation. I think it's a no brainer to use the fastest model to compact.
But even if it's not, why impose your view to the world? I mean, if it's complicated and difficult to implement I would agree; but if it's a philosophical reason because in your view everything is a prompt, I think this is a bit too restrictive to the people who might not share your view. And also a bit optimistic... but that's my view.
PS: is prompt caching is king, why have subagents at all?
zikajk commentedon Aug 3, 2026
@apalazzi
Regarding the skill, what I meant was that you can call it via '/skill'. If you wanted it loaded at all times, there’s no reason not to make it a direct part of the agent's prompt itself.
When it comes to the sub-agent, the model choice is deterministic. Of course, the main agent can always decide not to follow your instructions, just like a sub-agent might decide not to execute a git operation you asked for. That’s just the nature of LLMs.
And I don't think this is just my personal take; it's purely about the semantics of these concepts. Skills and commands pertain to the current chat session—your proposal would essentially turn them into 'run a sub-agent with this prompt'.I don't think it's just my perspective, because I haven't seen a harness yet that would break those semantics.
Imagine how that would work. You want it to be deterministic, so it wouldn't be controlled by the user's instructions. It would be a forced process whose output gets injected into the main agent without context, which raises some questions.
I think the reason for using sub-agents is clear, but I’m purely pointing out the 'compact' scenario, where you hand over your entire conversation history to the model.
The best approach would be if you could show us a scenario where a standard command fails and the LLM ignores your instructions. Then it might be easier for me to suggest you a good solution.
apalazzi commentedon Aug 3, 2026
Then I have to make a prompt for every project and every skill combination, or activate them by hand each and every time? Doesn't seem all that practical.
All the more reason to be as deterministic as possible where we can if the model can decide to not follow the instructions given, especially on a production environment. LLMs are still not as good as someone depicts them.
Again: if something can be done in a deterministic way I don't see any reason or advantage to make a LLM - that can catastrophically fail - do that specific thing.
If it's deterministic then it's run by the user instruction by definition, it's just that the instructions are not passed through the chat but through some file. And those instructions would be followed 100% of the time, which is not the case if you feed them to the LLM.
And I'm still haven't seen an agent that fully respects what I write in AGENTS.md, skills or commands, so I prefer the deterministic way.
And it's your personal take to assume that LLMs always follow instructions perfectly, which is not the case in the real world.
I'm not arguing about the semantics of skills or whatever, I'm just asking a way to make the harness to what I want it to do - and asking the LLM is clearly not enough.
And I'm pointing out that there are cases where handing over your entire conversation history to a fast model is better that having a very slow model compacting the whole chat.
Like when I put in my AGENTS.md explicit instructions to load skills or specific instructions to follow on specific case, then the LLM doesn't load the skills or follow those instructions until I explicitly tell it to do that?