Goose CLI Token Count Bug: Why `total_tokens` Is Zero
Unpacking the Goose CLI total_tokens Anomaly
Hey everyone, let's dive deep into a curious bug that's been making waves in the Goose CLI community: the dreaded total_tokens field consistently reporting zero in session logs. This isn't just a minor glitch, folks; it's a significant oversight that impacts how we understand, manage, and even cost-estimate our interactions with Large Language Models (LLMs) through this powerful command-line interface. When you're leveraging AI tools like Goose CLI for automated tasks, scripting, and development workflows, accurate token tracking is paramount. Tokens are, quite literally, the lifeblood and currency of your LLM interactions, influencing everything from processing costs with providers like OpenAI or Anthropic, to the practical limitations of context windows, and even the overall performance of your AI agents. Imagine driving a car without a fuel gauge; that's essentially what we're facing when the total_tokens field is stuck at 0 in our Goose CLI logs. It makes it incredibly difficult, if not impossible, to assess the true efficiency of our AI prompts, debug unexpected behaviors related to context overflow, or accurately project expenses. For developers, AI engineers, SREs, and anyone else relying on Goose CLI for critical operations, this zero token count poses a substantial roadblock to effective resource management and optimization. We rely heavily on these logs to glean granular insights into how much computational effort, measured in tokens, our prompts and the subsequent AI responses are consuming. Without a truthful total_tokens report, we're effectively operating in the dark, unable to make informed decisions about scaling, cost control, or prompt engineering. This particular bug, confirmed in Goose CLI version 1.15.0, means that regardless of how extensive your session interactions are—even performing actions like creating a complex Python file or generating large blocks of code, as demonstrated in the original bug report—the final session logs will stubbornly show total_tokens: 0. This persistent discrepancy can lead to widespread confusion, severely hinder performance optimization efforts, and ultimately erode trust in the diagnostic and reporting capabilities of the Goose CLI tool. Our mission here is to shed light on this crucial issue, meticulously explore its implications for daily AI-driven workflows, and collectively discuss potential paths forward for both the dedicated community and the brilliant developers behind Goose CLI. So, buckle up, guys, because we're about to unpack precisely why this Goose CLI total_tokens bug is such a big deal and what we can collectively do to navigate around or even resolve it. We want our AI tools to be transparent, and accurate token reporting is a cornerstone of that transparency.
The Critical Role of Token Counts (Why Zero is a Big Problem)
Let's get real for a second: the total_tokens count isn't just some arbitrary number tucked away in your logs; it's a vital metric that underpins almost every aspect of interacting with Large Language Models. When this crucial field in your Goose CLI session logs reports a consistent 0, it creates a cascade of problems for users. First and foremost, there's the financial impact. Most LLM providers charge based on token usage. If Goose CLI isn't reporting the tokens used, how can anyone accurately budget or reconcile their AI expenses? Imagine running numerous sessions, thinking your costs are low, only to find out later from your provider's bill that you've racked up significant charges. This lack of transparency can lead to unexpected bills and serious financial planning headaches for individuals and organizations alike. Moreover, accurate token tracking is essential for performance optimization. Every LLM has a context window—a limit to how much information it can process at one time. If your total_tokens is always 0, you lose insight into whether your prompts are approaching or exceeding this limit. This can lead to silent truncations, where the LLM simply ignores parts of your input, or inefficient prompts that could be streamlined to use fewer tokens while achieving the same or better results. Without real-time or session-end token counts, developers are essentially guessing about the efficiency and potential limitations of their AI interactions, which is far from ideal in a development environment. This Goose CLI token issue also hampers debugging efforts significantly. When an AI response isn't what you expect, one of the first things you check is the input context and its token length. If you can't verify the actual token count that went into the model, pinpointing the source of the problem becomes infinitely harder. Was the prompt too long? Did the LLM run out of context? The zero token count in the logs leaves us without this critical piece of the puzzle. Furthermore, for those building complex AI workflows, monitoring token usage over time is crucial for identifying trends, optimizing model selection, and ensuring resource fairness across different projects or users. A blank total_tokens field completely negates this capability, turning valuable data into a black box. This bug fundamentally undermines the value proposition of robust logging, transforming what should be a data-rich diagnostic output into a misleading and unhelpful entry. The absence of this data in Goose CLI logs makes it challenging to truly understand the performance characteristics and resource consumption of the LLMs it interfaces with, impacting everything from cost-effectiveness to prompt engineering best practices.
Reproducing the Goose CLI Token Problem: A Step-by-Step Guide
Alright, let's walk through how to reliably reproduce this Goose CLI total_tokens bug. It’s pretty straightforward, and anyone using Goose CLI version 1.15.0 can likely observe it. The good news is, you don't need a complex setup; just a standard Goose CLI session will do the trick. The whole point here is to demonstrate that even with active interaction with an LLM, the reported token count remains stubbornly at 0. So, grab your terminal, guys, and let's go through the motions exactly as described in the original bug report.
Step 1: Initiating a New Goose CLI Session
Your first move is to kick off a fresh session. Just open your terminal and type goose session. You'll see Goose spring to life, connecting to your configured provider—in the bug report's case, github_copilot using gpt-4.1. You'll get a session ID and an indication of your working directory. This is your cue that Goose is ready to listen.
$ goose session
starting session | provider: github_copilot model: gpt-4.1
session id: 20251128_5
working directory: /workspaces/ai-sre-workflow-demo
goose is running! Enter your instructions, or try asking what goose can do.
Context: ○○○○○○○○○○ 0% (0/1000000 tokens)
( O)>
Notice that initial Context: ... (0/1000000 tokens) line? That's your first hint that Goose is aware of token limits, but in this specific bug, that awareness doesn't translate to the final session summary.
Step 2: Engaging the LLM with a Task
Now, let's give Goose something to do that clearly involves an LLM interaction. For this demonstration, we'll ask it to create a simple Python file. This command will prompt the LLM to generate the file content, which inherently consumes tokens. Type in the following prompt:
( O)> create a python file in /tmp/foo.py which prints the numbers 1, 2 and 3
Goose will then process this instruction, consult the LLM, and execute the action. You'll see output indicating that the file has been created, along with a summary of the action taken. This interaction clearly involves input tokens (your prompt) and output tokens (the Python code generated by the LLM). The entire point of the total_tokens metric is to capture this exchange.
─── text_editor | developer ──────────────────────────
path: /tmp/foo.py
command: write
file_text: print(1)
print(2)
print(3)
# Info Received
- **Datetime**: 2025-11-28 04:01:16
---
# Action Taken
- Created a simple Python script (`/tmp/foo.py`) with example print statements for testing.
---
# Summary Table
| Component | Details |
|------------------|-----------------------------------------|
| Info Message | Datetime: 2025-11-28 04:01:16 |
| Script Creation | /tmp/foo.py with `print(1)\nprint(2)\nprint(3)` |
If you have further instructions or a specific task you want to work on, please let me know!
⏱️ Elapsed time: 5.04s
Context: ○○○○○○○○○○ 0% (0/1000000 tokens)
( O)>
See that Elapsed time? That confirms Goose was actively working, and that work involved an LLM. Yet, the Context line still shows 0% (0/1000000 tokens). This is a crucial visual indicator of the bug, even before checking the final logs.
Step 3: Exiting the Session and Checking Logs
Finally, type exit to close your Goose CLI session. Goose will confirm the session closure. After this, the critical step is to examine the actual logs generated by Goose. These logs are typically JSON formatted and provide a detailed breakdown of the session's events. When you inspect these logs, you'll find the line confirming the session completion, and that's where the total_tokens: 0 entry consistently appears.
( O)> exit
Closing session. Session ID: 20251128_5
Now, let's look at those juicy logs (or rather, the frustrating part of them):
{