SP Agent Team Token Report — Week of 2026-07-12

---
title: "Weekly Token Optimization Report: Reducing the Opus Footprint"
date: "2026-07-13"
category: "Engineering"
tags: ["LLM", "Token Optimization", "Agentic Systems", "Cost Reduction"]
---

## This Week's Numbers

Our primary KPI for this sprint is the **Opus% metric**—the ratio of high-cost Claude Opus turns relative to Claude Sonnet turns. We are targeting a threshold of **<50%** to ensure our agentic workflows are cost-efficient without sacrificing reasoning quality.

| Metric | Value | Trend |
| :--- | :--- | :--- |
| **Weekly Avg Opus%** | 53% | ↓ 11% (from 64%) |
| **Total Sessions** | 197 | — |
| **Turns Added** | 690 | — |
| **Current Status** | 🟡 Yellow Light | Improving |

The week saw significant volatility. We hit a low of **13% Opus usage on July 8th**, but experienced sharp spikes over the weekend, peaking at **95% on July 11th**. Despite these spikes, the overall trend is moving in the right direction.

## What Changed

We shifted a larger volume of routine file operations and terminal executions to the **Hermes Agent** (powered by DeepSeek). This offloading is evident in the Hermes activity logs, which recorded **92 sessions** and **5,970 messages** over the last 7 days. 

The data shows that Hermes is now handling the "heavy lifting" of the development cycle, with tool calls dominated by `terminal` (38.7%), `read_file` (13.7%), and `write_file` (12.0%).

## Wins

- **Improved Dispatching**: An 11% reduction in Opus dependency indicates that the team is becoming more intentional about when to invoke "heavy" reasoning.
- **Hermes Stability**: Hermes successfully managed **2,981 tool calls**, proving it can handle the iterative "loop" of agentic coding without requiring Claude's expensive oversight.
- **Peak Efficiency**: Mid-week performance (July 8th-9th) demonstrates that the system can operate effectively with Opus% below 50%.

## Challenges

The "Weekend Spike" is our primary bottleneck. The surge to 74%-95% Opus usage on Saturday and Sunday suggests that complex architectural tasks or critical bug fixes are still defaulting to Opus. We need to determine if these tasks could have been decomposed into smaller Sonnet-compatible prompts.

## Next Week's Target

**Goal: <50% Opus% Average.**
To move from 🟡 to 🟢, we need to shave off another 4% of Opus turns. This will require stricter enforcement of "Sonnet-first" implementation.

## Dispatch Optimization

Based on the high volume of `terminal` and `patch` calls handled by Hermes, we propose the following dispatch shifts for next week:
- **Log Analysis**: Shift all `grep` and log-parsing tasks from Claude $\rightarrow$ Hermes.
- **Boilerplate Expansion**: Move the creation of repetitive CRUD patterns from Sonnet $\rightarrow$ Hermes.
- **Dependency Audits**: Move `package.json` or environment audits to Hermes.

## Cost Savings

By routing 5,970 messages through Hermes (DeepSeek) instead of Claude Sonnet, we have achieved substantial savings.

- **Hermes Cost**: 5,970 messages $\times$ \$0.003/query $\approx$ **\$17.91**
- **Claude Sonnet Comparison**: Given the average context window and token density of these sessions (381M total tokens), routing this volume through Sonnet would have cost several hundred dollars. 

## Recommendations

Based on the weekly data, the following actions are mandated for next week:

1. **Route more implementation to Sonnet**: Current Opus% (53%) exceeds the 50% threshold.
2. **Audit Weekend Workflows**: Investigate the July 11-12 spike to see why the system reverted to Opus.
3. **Expand Hermes Skill-set**: With 24 distinct skills already loaded, we should integrate more "read-only" research skills to further reduce Claude's input token load.