AdaL on X: "Adal is more token-efficient than Claude Code!! https://t.co/QnU3UvKSWr" / X<br>Post

Log inSign up

Post

AdaL

@adalagent

Adal is more token-efficient than Claude Code!!<br>When Building Gets Cheap, Knowing What to Build Gets Expensive<br>When building gets cheap, knowing what to build gets expensive.<br>AI coding agents have made it surprisingly cheap to turn an idea into working code. That sounds unambiguously good, but it creates a new failure mode: we can now build the wrong thing much faster.<br>We ran into this recently while working on AdaL. We had a strong feeling that AdaL was less token-efficient than Claude Code, and the initial investigation seemed to support it. We found architectural differences that could explain the gap, and agents quickly produced several plausible fixes.<br>A year ago, those fixes might have been expensive enough to force a careful debate. Now an agent could implement some of them in hours. So instead of building them, we built the benchmark first.<br>The benchmark told us our intuition was wrong. Adal is more token-efficient than Claude Code.<br>Plausible ideas are getting dangerously cheap<br>Our original observation was simple: AdaL felt more token-hungry than Claude Code in long sessions.<br>The first breakdown showed that tool-call results occupied roughly 80% of the context window. That immediately suggested a mechanism: older tool output often contributes less to the current decision, so perhaps carrying all of it forward was an important source of inefficiency.<br>We then compared how Claude Code, OpenCode, and Pi appeared to handle long histories and tool results. Agents were extremely useful here. They could inspect architectures, identify differences, and generate possible improvements much faster than we could manually.<br>One idea looked especially compelling: compact old tool-call results after five or ten turns. The reasoning was straightforward. If old tool output dominates the context while contributing less over time, making it smaller should reduce token usage.<br>It was exactly the kind of explanation that could turn into a feature before anyone had established that the original problem was real.<br>A plausible explanation is not evidence that there is an opportunity worth solving.<br>Cheap implementation makes that distinction more important, not less.<br>Reverse the feature loop<br>The usual product loop looks something like:<br>idea → research → design → implementation → launch → measurement<br>For ambiguous R&D, we've started preferring a different sequence:<br>idea → observability → hypothesis → metrics → benchmark → decision → implementation<br>The important change is where implementation happens. Instead of asking whether an agent can build a proposed improvement, we first ask whether we can demonstrate an opportunity worth building for. If we don't know how to measure the improvement, the first deliverable should be the measurement, not the feature.<br>Only then could we ask the product question that mattered: is the gap large and consistent enough to deserve engineering time?<br>The first benchmark rejected our hypothesis<br>We first ran AdaL and Claude Code on a subset of SWE-bench, using the same model and effort setting and repeating the benchmark three times.<br>We expected Claude Code to be more efficient. Instead, in the displayed run, both systems reached the same 50% pass rate — 25 out of 50 tasks — while AdaL reported lower total cost: $31.94 versus $42.09. AdaL was also slightly faster in this run, averaging 511 seconds per instance versus 563 seconds.<br>Figure 1. SWE-bench subset comparison. Both harnesses reached a 50% pass rate (25/50); the displayed AdaL run reported $31.94 in total cost versus $42.09 for Claude Code.<br>This didn't prove that AdaL was universally more efficient. The benchmark covered a limited task set and one style of usage. But it did reject the simplest version of our original belief: we could no longer claim that AdaL was obviously less token-efficient on long-running coding tasks.<br>That left another possibility. SWE-bench is mostly headless: the agent receives a task and continues with little additional user input. Real developers use coding agents interactively, changing requirements, asking follow-up questions, requesting explanations, and redirecting work over many turns.<br>Maybe AdaL performed well headlessly but became less efficient as conversations grew.<br>So we tested that instead.<br>We changed the hypothesis instead of defending it<br>Using the SDKs exposed by AdaL and Claude Code, we simulated increasingly long interactive sessions: single-turn queries, short conversations, and longer multi-turn sessions.<br>We kept the comparison as controlled as possible and inspected how much context each system re-fed as conversations grew. The result was much less dramatic than our intuition suggested. Across the displayed scenarios, context usage remained in roughly the same range: essentially identical in the one- and three-turn cases, lower for AdaL in the five-turn case, and about...