How a single-GPU coding agent uses language models, deterministic execution, persistent memory and MCP—and what three models revealed about autonomous software development.
Technical feature | 21 October 2026 | Current development baseline: v0.9.1
Generating source code is no longer the difficult part of AI-assisted programming. The harder problem begins when a system must act independently: inspect an unfamiliar repository, identify a defect, change the right files, run tests and distinguish a plausible completion report from work that actually succeeded.
REAPER-AI is a local engineering agent designed around that distinction. The language model proposes actions; deterministic Python tools execute them and record evidence. The current development line includes native Model Context Protocol (MCP) support, persistent working state and a compact browser interface.
What REAPER-AI Can Do Today
Functional overview — v0.9.1. REAPER-AI operates directly on local projects: it can inspect an unfamiliar codebase, locate relevant source, execute commands, modify files, check results and recover interrupted runs. These functions are available through one local application rather than independent agents or services.
| Capability | Implemented behavior |
| Autonomous coding | Investigates coding tasks, creates or edits files, applies targeted patches and checks the result. |
| Repository inspection | Uses file and text search, Python symbols, imports, line-range reads and an incremental repository index. |
| Editor and navigation | Provides project file trees, editor tabs, syntax highlighting and hash-protected saving. |
| Commands and Git | Runs shell commands, discovers Python installations and inspects Git status and diffs. |
| MCP tools | Discovers and invokes external tools through stdio or Streamable HTTP MCP servers. |
| Projects and history | Separates project configurations, conversations, run history and scoped durable knowledge. |
| Memory and checkpoints | Retains confirmed tool facts, open questions, verification evidence and recoverable execution state in SQLite. |
| Run supervision | Supports timeouts, cancellation and explicit checkpoint recovery on the current Windows execution platform. |
| Live diagnostics | Displays recorded tool activity, decision traces, model-thinking data when provided, errors and verification outcomes. |
Scope of autonomy: these are implemented capabilities, not a guarantee of reliable task completion. Source changes and functional checks provide stronger evidence than model-generated final reports; v0.10.0 therefore focuses on repeatable coding quality and avoiding redundant tool actions.
1. An Agent Is More Than a Code Generator
A conversational assistant returns text. A coding agent must maintain a sequence of operations against files and processes that can change during execution. Read results may become stale; a patch can conflict with a newer version of a file; a failing test can indicate either a defective implementation or a bad test invocation.
REAPER-AI separates the model from the execution machinery. It treats model reasoning as a proposal and the observed tool result as evidence. A model statement that a test passed cannot replace a recorded successful test command.
2. A Deliberately Small Architecture
The application uses Python 3.12+, embedded LangGraph, local Ollama inference, FastAPI, SQLite, and an HTML/CSS/vanilla-JavaScript frontend. Neither a cloud-hosted agent platform nor a distributed service layer is necessary.
Figure 1 — Main logical responsibilities in the local execution stack.
On the development workstation, an RTX 5090 with 32 GB of VRAM hosts the quantized local coding models. REAPER-AI itself does not depend on that specific GPU. The selected model runs through Ollama; filesystem, Git and process operations run with the ordinary permissions of the user starting the application.
3. Sentinel and the Execution Cycle
Sentinel implements an iterative Prepare–Decide–Execute–Observe–Finalize cycle. Ollama supplies a structured JSON decision, including the next tool and its arguments. A single dispatcher invokes the operation and normalizes its result: success, exit status, output, duration, errors and observed changes.
Figure 2 — Sentinel continues from observed tool results until sufficient evidence supports finalization.
Built-in tools cover repository inspection, targeted file reads, search, Git operations, shell commands and source modifications. Existing-file changes use SHA-256 conflict checks. The focused apply_patch operation also requires the original fragment to occur uniquely, avoiding an accidental broad replacement.
Supervised runs use timeouts and cancellation. REAPER-AI does not automatically commit, push, tag or release changes. A completed run records an observed execution outcome, not a formal guarantee of semantic correctness.
4. Repository Index and Memory
Sending an entire repository to an LLM is costly and often unnecessary. REAPER-AI maintains a project-local index of paths, hashes, file metadata, Python AST symbols and imports, with optional Git information. Sentinel can narrow an investigation to relevant modules and source ranges rather than repeatedly reading complete files.
Checkpointed working memory keeps observed facts separate from model-generated interpretations, open questions and verification results. It also distinguishes retained source coverage from the excerpts actually visible in a particular model decision. This design responds to real failures in which agents re-read known ranges or treated unverified conclusions as established facts.
SQLite stores projects, conversations, runs, structured events, checkpoints and scoped durable memory. Durable project knowledge consists of explicit user decisions and observed execution summaries; routine model prose does not silently become verified memory. Interrupted runs can be resumed explicitly from a valid checkpoint.
5. MCP: Tools Without a Second Agent
REAPER-AI v0.8.0 introduced native MCP tool discovery and execution using stdio and Streamable HTTP. MCP tools enter the existing dispatcher rather than requiring a second orchestration framework. Configuration is stored in mcp.json. The web-based management of MCP servers and discovered tools is still planned.
MCP widens the range of operations available to Sentinel, but does not make the model more reliable. The agent must still select the correct operation, interpret its output, avoid unproductive repetitions and determine whether the original request has been fulfilled.
6. Three Models, One Bug
The most useful comparison tested Qwen3.8-Q5, Qwen3.6-35B-A3B and Devstral Small 2 on identical isolated Python CLI projects. A transaction-report utility excluded negative amounts, so refunds failed to reduce category totals. The expected value for books was 15.00; the faulty program returned 20.00. Each model had to investigate, correct and independently verify the defect.
Figure 3 — Runtime in the autonomous bugfix benchmark. The fastest run did not produce a working fix.
| Metric | Qwen3.8-Q5 | Qwen3.6-35B | Devstral Small 2 |
| Runtime | 157.2 s | 44.0 s | 186.0 s |
| Model calls | 31 | 11 | 46 |
| Tool calls | 30 | 10 | 46 |
| Input tokens | 123,366 | 39,702 | 272,292 |
| Repeated actions | 18 | 2 | 38 |
| Functional outcome | 3/3 tests pass | Bug remains | Bug remains |
Qwen3.8 was the only model to remove the faulty nonnegative-amount guard, preserve the interface and pass three independent tests. Yet it repeated 18 actions, mostly already-successful verification steps. Its implementation succeeded; the strict no-repeat benchmark did not.
Qwen3.6 identified the correct defect but never changed the source or ran functional verification. It nevertheless reported that the bug had been fixed. Devstral consumed substantially more tokens and tool calls without completing a repair within the target window.
The earlier read-only D01 and S03 comparisons showed related patterns: Qwen3.6 could stop quickly with wrong technical conclusions; Devstral repeatedly requested available information; Qwen3.8 generally progressed further but still produced occasional inaccurate claims. These are individual recorded tests under this agent contract, not universal rankings.
D01 and S02: Testing Autonomy and Source Context
D01 — Autonomous Repository Analysis
D01 examined whether Sentinel could investigate an existing repository without modifying it: locate relevant implementation, use file and index tools, recover from ineffective or invalid reads, and produce a source-grounded technical report. Assessment separated execution, factual accuracy and efficiency. A terminal completed status was not treated as proof that its findings were correct.
In the Qwen3.8-Q5 acceptance run (d01-1792496155), Sentinel completed after 128.9 seconds, 18 model calls and 17 tool calls. It recovered from two invalid line-range requests and avoided repeating a successful source range. The externally reviewed report nevertheless received only grade 3 for factual accuracy, including an incorrect claim about Git subprocess timeouts. Overall D01 grade: 3; execution grade: 2. Qwen3.6 finished in 25.0 seconds after only three tool calls but produced largely incorrect or overstated conclusions; Devstral timed out at 600.2 seconds after repeatedly indexing files already discovered. Thus D01 established a viable autonomous investigation loop, not dependable technical judgment.
S02 — Relevance-Based Source Selection
S02 addressed a failure observed in earlier analysis runs: useful code excerpts could be displaced by older context or incorrectly treated as complete source coverage. The change ranks individual snippets by relevance to the current question and task. The system now records separately which source ranges have been captured and which ranges are actually visible in the next model prompt; a truncated targeted read no longer becomes weak evidence merely because it is not a whole-file capture.
S02 was verified through focused source-coverage and decision-context checks and subsequent diagnostic runs. The associated D01 rerun showed progressive, non-identical reads instead of the previously observed repetitive range pattern. This supports the effectiveness of the source-selection correction in the tested circumstances, but it is not an independent three-model S02 benchmark and does not guarantee accurate interpretation. Later S03 tests continued to reveal model-dependent reasoning and repetition despite relevant source being visible.
The combined lesson is straightforward: source availability, model attention and factual correctness are separate properties. An agent must receive the right evidence, use it to make progress, and then substantiate its conclusions independently.
7. The Browser as an Instrument Panel
The frontend combines project navigation, file browsing, an integrated source editor, chat tabs and run diagnostics. Live SSE events expose actual tool operations; Decision Trace exposes presented evidence, chosen actions and recorded outcomes. Separate Ollama thinking output is shown only when the runtime supplies it.
Figure 4 — Current REAPER-AI interface: file tree and editor at left/center; live events, decision trace and model diagnostics at right.
The interface is intentionally less like a conversational demo and more like a technical instrument panel. Autonomy is hard to assess if the operator sees only the final answer. Source changes, errors and checks must remain inspectable.
8. Failures, Recovery and the Road to 1.0
Recorded failures include repeated source reads, verification loops, malformed or premature decisions and false completion claims. Version 0.9.1 improves evidence-linked questions and relevance-based context selection, but it does not establish general reliability across repositories or models.
The current autonomous supervisor remains Windows-specific. POSIX process supervision, practical Linux/macOS acceptance, visual diff review, MCP management and more direct navigation between events and changed code remain development targets. Version 0.10.0 concentrates on multi-file coding, test-backed completion and recovery from mistakes without model-specific workaround layers.
Conclusion
The architecture required to run a local coding agent is relatively modest. Python, an embedded execution graph, a local LLM runtime and one SQLite database are sufficient for a functional system. The difficult part is the relationship between a task, the evidence collected, the changes made and the point at which work may credibly be called finished.
The three-model benchmark captures that problem neatly: one model found the defect and did not fix it, another invoked many tools without progress, and the only model that repaired the software spent too long proving it. REAPER-AI has demonstrated that autonomous coding can work on consumer hardware. Consistency, factual accuracy and efficient completion remain the engineering challenge.
Technical basis: REAPER-AI README, ARCHITECTURE, ROADMAP and MODELCHOICE (21 October 2026); Three-Model Autonomous Bugfix Benchmark. Repository: https://github.com/robertbackhaus-a11y/REAPER-AI