Summary
Currently, starting agentapi and passing flags is the responsibility of individual agent modules rather than a shared base agentapi module. This leads to repeated code across modules.
Current State
Each module implements its own agentapi invocation with various flags:
agentapi server --type opencode --term-width 67 --term-height 1190 -- opencode "${ARGS[@]}"
agentapi server --type amp --term-width=67 --term-height=1190 -- bash -c "echo \"$PROMPT\" | amp" "${ARGS[@]}"
agentapi server --type claude --term-width 67 --term-height 1190 -- claude "${ARGS[@]}"
agentapi server --term-width=67 --term-height=1190 -- aider --model $ARG_MODEL --yes-alwaysProposed Improvement
-
A configuration agentapi module could provide a standardized agentapi command that operates in a certain way (e.g., with regards to state persistence)
-
Common configuration options could be passed as module variables:
--type--term-width--term-height--state-file
-
Agent-specific startup logic can be written to a shell script that gets executed by the agentapi server:
agentapi server --type claude --state-file="/tmp/agent.state.json" --term-width 67 --term-height 1190 -- ./start-agent.sh
Related
Created on behalf of @work-jaykumar
Summary
Currently, starting agentapi and passing flags is the responsibility of individual agent modules rather than a shared base agentapi module. This leads to repeated code across modules.
Current State
Each module implements its own agentapi invocation with various flags:
Proposed Improvement
A configuration agentapi module could provide a standardized agentapi command that operates in a certain way (e.g., with regards to state persistence)
Common configuration options could be passed as module variables:
--type--term-width--term-height--state-fileAgent-specific startup logic can be written to a shell script that gets executed by the agentapi server:
agentapi server --type claude --state-file="/tmp/agent.state.json" --term-width 67 --term-height 1190 -- ./start-agent.shRelated
Created on behalf of @work-jaykumar