When working on gpt-engineer I notice one benefit which is that the context per request is a lot smaller, because we don't keep sending past conversation history. This also saves massively on OpenAI spend.
This could be achieved by giving gptme a "subagent" tool, which can run a complex tasks that require back-and-forth, and for which the required context is clearly scoped, and a clear-defined result.
Examples of such tasks include:
performing some data analysis where we are only interested in the answer/resulting plot
writing & applying a code change with a set of files as context/input (potentially with use of #59)
This might require some change to the data model, to support the notion of subconversations, or perhaps an arbitrary metadata field that isn't send to the LLM, and can thus be used to store subconversations.
Or maybe we just store all subconversations as their own files (possibly in their own directory), and reference them in the raw conversation log.
The user should be able to interact with the subconversation (if needed, to debug or such).
When working on gpt-engineer I notice one benefit which is that the context per request is a lot smaller, because we don't keep sending past conversation history. This also saves massively on OpenAI spend.
This could be achieved by giving gptme a "subagent" tool, which can run a complex tasks that require back-and-forth, and for which the required context is clearly scoped, and a clear-defined result.
Examples of such tasks include:
This might require some change to the data model, to support the notion of subconversations, or perhaps an arbitrary metadata field that isn't send to the LLM, and can thus be used to store subconversations.
Or maybe we just store all subconversations as their own files (possibly in their own directory), and reference them in the raw conversation log.
The user should be able to interact with the subconversation (if needed, to debug or such).