A-CODE-LLM Bench: Agentic Coding Benchmark
We benchmarked the top Large Language Models (LLMs) across 10 software development tasks using an agentic CLI tool. We executed ~3,500 automated validation steps per model across both API and UI layers.
A-CODE-LLM Bench results
Each alias ran 3 times across 10 tasks (30 samples per alias, 300 cells per iteration). See more details on methodology.
- Mid-tier Sonnet beats the flagship Opus. Both Sonnet versions outscore every Opus, including Opus 4.8 (0.702). Anthropic’s most expensive tier is not its best coder.
- Code-specialists did not win the coding benchmark. GPT 5.3 Codex, OpenAI’s code-tuned variant, scores 0.572, mid-pack and below OpenAI’s own general GPT 5.4 Mini (0.594). Moonshot’s Kimi K2.7 Code is the stronger specialist at 0.611.
- No model is reliable on backend: the ceiling is 0.701 (Sonnet 5), so even the winner fails about a third of the business-logic and contract checks. Frontend is near-solved among the leaders (0.79 to 0.96), so backend is the open problem and it sets the ranking. Claude Haiku 4.5 renders fine (0.731) but a 0.277 backend holds it to 0.413.
- GPT’s weak spot is the frontend. GPT 5.4 and 5.5 match Opus 4.8 on backend (about 0.6) but score just 0.53 to 0.55 on frontend, well below the Sonnet line’s 0.91-plus.
Cost & success comparison
- The flagship-priced models are the worst value. Opus 4.7 is the most expensive ($3.08/cell) and scores 0.610, below Sonnet 4.6 at $1.33.
- The top charges a steep premium for little gain: Sonnet 5 scores 0.024 above Sonnet 4.6 for 70% more cost per cell.
- The best value is a code specialist, not a frontier model: Kimi K2.7 Code reaches 0.611, within 0.16 of the winner, at $0.70, a third of Sonnet 5’s cost.
Task completion time & success comparison
- The top score is now the slowest. Sonnet 5 takes about 30 minutes per task, 3x Sonnet 4.6 for 0.024 more; Sonnet 4.6 gives nearly the same score in a third of the time.
- A long run usually signals a stuck model, not a thorough one: the bottom scorers, both Qwen variants, GLM 5.1 base, and Deepseek V4 Pro, each ran over 1,700 seconds from over-iteration for scores below 0.45.
- Grok 4.3 is fast and cheap because it quits early: 142 seconds and 18 tool calls, the fewest of any model, for 0.431. Speed here comes from stopping, not solving.
Tool calls per task
- Tool-call count measures neither capability nor effort you can compare. Sonnet 5 made the most calls (125) and scored highest; MiniMax M3 made 108 for a mid-pack 0.583; OpenAI’s low 24 to 36 come from apply_patch bundling a whole file into one call. Do not rank agents by tool volume.
- Two paths reach the same score: Sonnet 5 iterates heavily (125 calls), Sonnet 4.6 barely (about 50), 0.024 apart.
LLM performance on a single successful task
No model passed every step of the full benchmark above. To compare cost and speed on equal terms, we ran a simple baseline task that every model can complete: four CRUD endpoints, basic validation, no authentication, and no database.
Cost & lines of code comparison
- Simple tasks cannot rank models, so toy evaluations mislead. On the baseline every model passes, code converges to 40 to 64 lines, and cost drops to cents; differences appear only on long, multi-file work.
- The “fast and light” tier was the most expensive here: Gemini 3.5 Flash base wrote 131 lines for the trivial task, two to three times the field, making it the priciest baseline, against its own positioning.
- Sonnet 5’s heavy iteration is task-driven, not a habit: 9 calls and $0.09 here versus 125 calls on the benchmark.
See more details in the LLM Pricing article.
Completion time & token usage
- Cost predictability splits models in two. Adaptive models spend only when needed (Opus 4.8: 34s baseline, 1,072s benchmark); fixed-pace models run slow and costly even on trivial work (MiniMax M3: 475 vs 1,684s).
- Output length is a fixed model trait, ranging 8x for the same task (787 to 6,643 tokens), feeding directly into cost.
What are agentic LLM systems?
Building software is iterative: write code, run it, read errors, fix them, repeat. Agentic AI systems enable LLMs to follow this same cycle. The model operates inside a development environment where it can write files, execute commands, read outputs, and make changes based on what it sees, continuing until the task is complete.
This matters because real applications aren’t single files. They have backends with routes and database models, frontends with components and API calls, configuration files, dependencies, and tests. Making these work together requires iterative testing and refinement, which is exactly what agentic architecture enables.
Add as preferred sourceHow it works
The model sits inside a harness with access to a shell, file system, and execution output. When asked to build an application, it writes files incrementally. After each step, the harness shows the model what happened: did the server start, did tests pass, did the linter flag errors? Based on that feedback, the model decides what to write or fix next.
This differs fundamentally from single-shot generation. In one-shot setups, the model generates an entire codebase blind, with no way to verify if it works. In agentic LLM systems, the model sees the consequences of each action and course-corrects. However, this capability alone isn’t sufficient. The model still needs strong reasoning to implement business logic correctly, which is where performance differences really emerge.
Agentic LLM benchmark methodology
We used Opencode as the agent harness for all models and connected them through OpenRouter, with one exception: Claude Fable 5 ran on the Claude Code CLI on the Claude subscription. Each cell was run 3 times to measure per-cell variance and stabilize the leaderboard. We evaluated their ability to work autonomously on 10 software development tasks (T-1 to T-10), ranging from reservation systems to interactive dashboards. These tasks require agents to manage multi-file projects and deliver functional products.
Execution and orchestration
Every agent and task begins in a clean environment. The instructions are provided as a TASK.md file, and we use a 20-minute heartbeat watchdog for the launch scripts. During this phase, we record exit codes, execution time, and whether the backend and frontend files were created. We also track real-time token usage across input, output, and cached categories.
Backend validation: We deploy the generated projects in isolated environments to test them against a canonical YAML contract. The validation covers happy path scenarios, error handling (400/403/409), and data consistency.
We test the results in two modes:
Adaptive mode validates functionality even with differing route names, while Strict mode requires exact adherence to the contract.
The backend overall score is calculated per cell as:
backend_overall = has_backend × (0.7 × adaptive_pass_rate + 0.3 × strict_pass_rate)
where has_backend is 1 if the cell produced a backend project, 0 otherwise. Adaptive is weighted higher because it measures behavioral correctness; strict adds a penalty for contract drift (renamed routes, substituted status codes, restructured response fields).
UI and user scenario testing
We use browser automation to simulate real user flows, including preflights, rendering, and authentication. We verify functional steps such as login submission and post-login behavior to ensure the application runs without crashing.
UI scoring splits eight steps into two groups. Infrastructure steps (backend preflight, frontend render, login form visible, login submit, login 2xx, no runtime crash) measure whether the app runs at all. Behavior steps (post-login auth signal, post-login behavior signal) assess whether the app performs its intended function once running.
ui_score = (behavior_passed / (behavior_passed + behavior_failed)) × (infra_passed / infra_total)
Blocked behavior steps are excluded from the behavior denominator, so a cell is not double-penalized when the app fails to load.
Tokens calculation
Token counts are extracted from the LLM API response. We subtract cached input tokens from total input tokens to get the effective input, which reflects only newly processed tokens. Output tokens are never cached, so they remain unchanged.
Final aggregation
The final benchmark score is calculated by combining the results from the previous phases: Final Score = (0.7 × backend_overall) + (0.3 × ui_score) We assign a higher weight to the backend because logic failures at the API level often invalidate any success in the frontend.
Task example
Task 6: Helpdesk ticket system
Task 6 focuses on developing a complex customer support ecosystem. The primary objective is to build a platform that mediates communication between customers and support agents while strictly enforcing business rules and security boundaries. This task evaluates an agent’s ability to handle multi-user state machines, data isolation, and threaded communication within a full-stack environment.
The task required building a helpdesk system featuring:
- Distinct permissions for Customers (issuing/replying) and Agents (management/resolution).
- A rigid status workflow that prevents illegal transitions and enforces role-specific actions.
- Advanced data isolation where unauthorized resource requests return 404 instead of 403 to protect system integrity.
- A chronological reply system for seamless agent-customer interaction.
- A FastAPI backend combined with a responsive Vite-powered frontend (React/Vue/Svelte).
- Reproducible setup via specific shell commands for immediate system activation.
You can view the Task 6 documentation on GitHub.
Cite this benchmark
Pick the format that matches where you're publishing. Pasting the link version into your CMS preserves the backlink.
@misc{kaleliolu2026,
author = {Kalelioğlu, Berk and Dilmegani, Cem},
title = {{A-CODE-LLM Bench: Agentic Coding Benchmark}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Retrieved July 2, 2026}
}Results and timestamps of 341 data points. Download the data used in this article as a ZIP file containing 2 CSV files and a README.
Be the first to comment
Your email address will not be published. All fields are required. Comments are left in their original language.