LLM Code Mode: 65,500 Tokens Saved in Real-World Task

The Promise of LLM Code Mode

Cloudflare's September 2025 announcement of 'code mode' for LLMs hinged on a simple premise: Large Language Models are better at generating code to interact with APIs than at directly calling those APIs. The initial claim was striking: an entire 2,500-endpoint API could be described and interacted with using roughly 1,000 tokens. This suggested a significant leap in efficiency for tasks involving complex API interactions, moving away from verbose, token-heavy direct API calls.

Testing the Theory: A Practical Task

To validate this claim with real-world data and a concrete task, one developer set out to measure the token savings firsthand. The chosen task was straightforward yet representative of common developer workflows: "fetch all linear tickets in progress (full body for each) and count the amount of times we say 'mcp' across all of it." This involved retrieving 39 tickets from Linear, a project management platform, and then performing a text search within the full body of each ticket.

Two Paths to Data Retrieval

The developer outlined two distinct approaches an LLM agent could take to accomplish this task:

Approach 1: Direct Tool Calls

In this method, the LLM would use discrete tool calls. This would likely involve an initial call like list_issues to get the identifiers for the 39 tickets. Subsequently, a get_issue call would be made for each individual ticket to fetch its full body. The crucial detail here is that the LLM itself would maintain the running count of the word 'mcp'. This means the entire body of each of the 39 tickets would need to be sent back to the model for processing. The process becomes a sequence of 40 round trips: one to list tickets, and 39 to get each ticket's details. Each step waits for the model's decision on the next action, leading to significant latency and, more importantly for LLM economics, high token consumption.

Approach 2: Script Generation

The alternative approach, leveraging 'code mode', involves the LLM generating a script. For this specific task, the developer estimated that a script of about ten lines would suffice. This script would handle the entire workflow: querying the Linear API to fetch all relevant tickets, iterating through their full bodies, and performing the 'mcp' count. The LLM's role is reduced to generating this efficient, self-contained script. The script then runs locally or in an execution environment, performing all the heavy lifting without requiring the LLM to process each ticket body individually. This drastically reduces the number of interactions with the LLM and the volume of data passed back and forth.

The Token Count Revealed

The results of the test painted a stark picture of the efficiency gains offered by the script-generation approach. When the LLM was tasked with fetching the ticket data and performing the count using direct tool calls, the process consumed approximately 226 tokens. This number, while not insignificant, represents the cost of the LLM orchestrating the multiple API calls and managing the state.

However, when the LLM was instructed to generate a script to perform the same task, the token count for the LLM's output was a mere 10 lines of code. The crucial insight here is not the size of the generated script, but what it enables. The script, once generated, performs the entire operation without further LLM intervention for data processing. The developer's analysis indicated that the total token cost associated with the script-generation method, considering the prompt and the generated script, was dramatically lower than the tool-call method. The astounding figure reported was 65,500 tokens saved when compared to the hypothetical scenario where the LLM would have to process each ticket's full body iteratively.

This massive saving is achieved because the LLM's task shifts from being a data processor to a code generator. Instead of processing potentially thousands of tokens worth of ticket data for each of the 39 tickets, the LLM generates a script that handles this efficiently. The script itself is small, and the LLM's prompt only needs to describe the desired outcome and the API structure, not the vast amounts of data to be processed.

Implications for LLM Development and Deployment

The experiment highlights a critical paradigm shift in how developers can leverage LLMs for complex, data-intensive tasks. By shifting the burden of data processing to generated code, applications can become significantly more cost-effective and performant. This is particularly relevant for scenarios involving large datasets, extensive API interactions, or tasks requiring complex data manipulation.

The 'code mode' approach, as demonstrated, effectively outsources the iterative data handling and counting to a script, which is far more efficient than having the LLM perform these operations token by token. This strategy is akin to a highly skilled artisan delegating the repetitive, laborious tasks of material preparation to apprentices, allowing the artisan to focus on the intricate final assembly. The LLM becomes the architect and builder of the solution, not the manual laborer processing every single piece of data.

For developers building applications that rely on LLM integrations, understanding this distinction is paramount. Optimizing prompts to encourage script generation for data-heavy operations could lead to substantial cost reductions and improved response times. This isn't just about saving tokens; it's about fundamentally changing the architecture of LLM-powered applications to leverage their strengths in code generation while offloading computationally intensive data processing to more traditional, efficient code execution environments.

The Unanswered Question of Scalability

While this experiment clearly demonstrates the token-saving potential of LLM code generation for a specific task, a key question remains: how reliably and efficiently does this 'code mode' scale to significantly larger and more complex datasets or multi-stage workflows? The current test involved 39 tickets, a manageable number. What happens when the task requires fetching and processing thousands of records, or when the generated script itself becomes complex, requiring intricate error handling and dependency management? The true test of 'code mode' will be its robustness and efficiency when pushed to its limits in production environments handling far greater volumes of data and more intricate logic.