Cut Token Costs by 90%: How ProjectAtlas Slashes AI Coding Agent Expenses in Production

I’m Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany, running DennisCraft AI Studio. I ship multi-agent AI systems for DACH B2B clients in logistics, fintech, and industrial automation on a stack of Claude, Supabase, n8n, Doppler, and self-hosted Postgres. Token spend in production isn’t a theoretical debate: one of my Claude Code deployments burned through a monthly token budget in just six days due to agent overactivity.

Where Token Waste Happens: Concrete Failure Points

1. Redundant LLM Calls (No Caching)

In production, I observed that 67% of LLM requests repeated previous queries—agents kept asking Claude Code for similar outputs without caching. The root cause: agent architectures often lack intermediate caching for both prompts and chain-of-thought outputs. Solution: implement a two-tier cache (Supabase for persistent, Redis for fast lookups), storing responses keyed by prompt and context.

import hashlib
import json
from supabase import create_client

def make_cache_key(prompt, context):
    return hashlib.sha256((prompt + json.dumps(context)).encode()).hexdigest()

def fetch_or_generate(prompt, context, supabase):
    key = make_cache_key(prompt, context)
    cache = supabase.table('llm_cache').select('*').eq('key', key).execute()
    if cache.data:
        return cache.data[0]['result']
    # Call Claude Code and cache the result
    result = call_claude_code(prompt, context)
    supabase.table('llm_cache').insert({'key': key, 'result': result}).execute()
    return result

2. Over-Decomposition: Agents Fragmenting Tasks

In one industrial client’s pipeline, a single CRUD API generation task was split into 15+ LLM calls: "analyze schema" → "write models" → "write endpoints" → "write tests"—each step a separate request. This over-decomposition increased average token cost by 10x versus batching the entire pipeline in a single prompt.

The fix: aggregate steps using explicit prompt engineering. Describe the whole process in one prompt, minimize call count, and only break out steps when truly required.

3. Reflection/Autofix Loops: Hidden Token Sink

Many agent pipelines follow a "generate–self-review–autorepair" pattern. Across three of my recent deployments, up to 40% of token usage came from these internal review/autofix loops, with only marginal gains in code quality. A 2023 Anthropic developer note (source) also cautions that model self-reflection isn’t a substitute for strong pre-prompt validation and post-gen static analysis.

ProjectAtlas: What Actually Cuts Costs in Production

1. Agent Reducer: Batch Prompts, Not Micro-steps

Instead of multi-call micro-steps, I use batch prompts that explicitly describe the end-to-end task. Example: generating a Postgres schema, FastAPI CRUD endpoints, and tests all via one prompt. This cuts LLM call count from 10–15 to 2–3 per task.

batch_prompt = (
    "Generate a Postgres schema, FastAPI CRUD endpoints, and unit tests for the following job:\n"
    f"{task_description}\n"
    "Output: JSON with keys schema, endpoints, tests."
)
response = call_claude_code(batch_prompt, context)
result = json.loads(response)

2. Decompose Only Where External Validation Adds Value

I split agent pipelines only when integrating external checks: after code generation, trigger bandit and semgrep for static analysis, but avoid self-repair loops via LLM unless a real vulnerability is detected. This maximizes security impact without burning tokens.

3. Aggressive Task-Level Caching

Cache not just on input prompt, but also on intermediate artifacts (e.g., DB schema). If a similar task was run before, retrieve the artifact directly from Supabase, skipping LLM calls.

4. Strict Reflection Cap: One Autofix Step Max

Instead of endless self-correction, limit agents to a single autofix pass—only if a static analyzer (e.g., bandit) flags a real issue. Otherwise, log errors for human triage.

5. Token Spend Monitoring and Anomaly Detection

Using n8n, I built a tracker that logs every LLM call with tokens used, time, and task context. This surfaces anomalies (e.g., tasks using 5x the baseline tokens) and enables targeted pipeline optimization.

Results: Live Metrics and Real Savings

My public agent (live.gerdennisai.com) has consistently cut average token use by 89.8% over three months compared to the baseline workflow. Data is available on a live dashboard. Example: typical DAL+API generation now uses 14,500 tokens instead of 120,000.

FAQ

Which cache do you recommend for fast LLM workflows?

Supabase Postgres for persistent storage; Redis for low-latency lookups. I combine both in production.

Does batching steps impact code quality?

No, if your prompt is thorough and requirements are explicit. Always run static analysis (semgrep, bandit) post-generation.

How do you maintain traceability in batch generation?

All intermediate artifacts and logs go into Supabase. If a step fails, it’s easy to reconstruct the pipeline and debug.

What’s the value of token spend monitoring?

It reveals wasteful agent behaviors—any task 5–10x above baseline is flagged for review, leading to quick savings.

Can this approach work without n8n?

Yes, you can use Airflow or Prefect for orchestration, but n8n is easier for integrations and visual monitoring.

At which stage does your agent pipeline burn the most tokens in production—generation, autofix, or testing? I’d genuinely like to compare notes. I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.