sst
morph file edit tool using Fast Apply
still testing this so left it as a draft. Might need some conditional system prompt changes
still testing this so left it as a draft. Might need some conditional system prompt changes
curious which models you tested this with and what you found? no system prompt changes necessary?
Tested this with qwen3 and qwen3-coder running on ollama.
What a difference it makes! I didn't find a case where the edit failed yet.
P.S. No system prompt changes necessary.
I would ship this ASAP - it makes such a huge difference in quality and it is allot faster.
i guess my main question remaining is how this interacts with permissions config and other places where we support listing tools (agent config comes to mind). ideally any alt edit tool like this "becomes" the edit tool, so that any config interacting with edit applies to the morphedit tool when you choose to use it instead of the default edit. cc @thdxr
i guess my main question remaining is how this interacts with permissions config and other places where we support listing tools (agent config comes to mind). ideally any alt edit tool like this "becomes" the edit tool, so that any config interacting with edit applies to the morphedit tool when you choose to use it instead of the default edit. cc @thdxr
do the changes in the registry not address this?
i guess my main question remaining is how this interacts with permissions config and other places where we support listing tools (agent config comes to mind). ideally any alt edit tool like this "becomes" the edit tool, so that any config interacting with edit applies to the morphedit tool when you choose to use it instead of the default edit. cc @thdxr
do the changes in the registry not address this?
no, if someone has permissions for an agent configured to "edit: ask", for instance, then that won't get picked up if they're using "morphedit". we need to have a notion of replacing the default "edit" tool, instead
i guess my main question remaining is how this interacts with permissions config and other places where we support listing tools (agent config comes to mind). ideally any alt edit tool like this "becomes" the edit tool, so that any config interacting with edit applies to the morphedit tool when you choose to use it instead of the default edit. cc @thdxr
do the changes in the registry not address this?
no, if someone has permissions for an agent configured to "edit: ask", for instance, then that won't get picked up if they're using "morphedit". we need to have a notion of replacing the default "edit" tool, instead
Ah I get it now. Just pushed an update to address this
sorry, i could have been more clear about what i'm thinking. i'd still expect this morph tool to live in it's own tool definition/file, it should simply replace the edit tool in the registry if enabled. i think of it like the "default app" on iOS (email, calendar, maps, etc.); the user can swap out the default edit tool for their preferred edit tool, with morph being one of those options. does that make sense? this latest approach/commit won't scale well to other tools in the sense that edit.ts will be a mess, we definitely want to isolate each tool in it's own file.
sorry, i could have been more clear about what i'm thinking. i'd still expect this morph tool to live in it's own tool definition/file, it should simply replace the edit tool in the registry if enabled. i think of it like the "default app" on iOS (email, calendar, maps, etc.); the user can swap out the default edit tool for their preferred edit tool, with morph being one of those options. does that make sense? this latest approach/commit won't scale well to other tools in the sense that
edit.tswill be a mess, we definitely want to isolate each tool in it's own file.
AH ok yeah my bad. the new changes should reflect what youre saying
It would be helpful if it also supported setting the baseUrl to an alternate server, like OpenRouter. There are already existing provider definitions that could be used to define Morph as a provider, and rely on the existing provider api-key definition, not introduce a separate environment variable. The definition of api-keys as environment variables are a separate feature.
Also, I would suggest using a consistent terminology in that this is an 'apply' model, not an 'edit' model. Having a custom edit/instruct model (separate from the agent/orchestrator) would be another feature down the line.
Since there's also a gap in how edits and compacts are hardcoded and not customizeable, a new "support" mode could be introduced that allows the definition of these models as support agents, allowing a definition of the apply, edit, and compact models.
@adamdotdevin lmk if you want me to clean this up a bit if you want to get this in