cheap-agent-codex
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEX_HOME | No | The Codex home directory. The installer respects this variable and defaults to ~/.codex. | ~/.codex |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pingA | Check that the Cheap Agent server is running and report its version. |
| delegateA | Make any code change: use this for every edit, including small, mechanical, "quick" or multi-file ones; those are exactly what the cheap worker is for, and your tokens cost the user far more than its. One call: task = what to change, which files, how to check. The worker edits an isolated worktree, runs the checks, and lands an OK result (uncommitted) in your working tree; read the result block instead of re-checking. Pass difficulty, rated from the issue as the time an engineer new to the code needs to fix and test it: easy < 15 min, medium < 1 h, hard > 1 h. For multi-step work pass plan + steps instead of task. Plan format: one "# " line, then per step a "## " heading followed by "files: ", "do: ", "done-when: " (optional "dont:", "needs: ", "difficulty: easy|medium|hard"), each key at the start of its line, not a bullet. In done-when, |
| researchA | Find and explain code in this repository: asks the cheap read-only research worker a question (it reads the working tree, uncommitted changes included). Returns a short answer with path:line refs and a confidence; verify low-confidence answers before acting. |
| replyA | Answer a BLOCKED job's question and resume its worker in the same session. Returns the job's next result block (OK, FAIL, or BLOCKED again); for a job in a batch, the batch block at its next settlement. |
| jobsA | List jobs, show a job's last result block again, wait for a job or batch to settle, or cancel a running job (keeps its worktree). |
| landA | Land or discard finished jobs that did not land (PARTIAL, FAIL, CONFLICT…). apply: 3-way applies a job's worktree changes to your working tree, uncommitted (a conflict leaves the tree untouched); discard: deletes its worktree. One line per job. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool has a mostly distinct role: delegate creates work, reply unblocks existing work, jobs manages job state, land finalizes worktrees, research queries code, and ping checks health. There is some overlap because delegate, reply, and jobs can all return result blocks, but the descriptions make the intended entry points reasonably clear.
All names are short, lowercase, single-word commands, giving a consistent CLI-like style. The only notable deviation is 'jobs' as a plural noun while the others are mostly verbs, but the set remains predictable and readable.
Six tools is well-scoped for an asynchronous coding-worker orchestration server. Each tool covers a distinct lifecycle area, and none feels redundant or merely decorative.
The surface covers the full worker lifecycle: delegate work, research code, monitor/wait/cancel jobs, reply to blocked jobs, land or discard finished work, and health-check the server. No obvious dead ends are apparent for the stated purpose.