€11 for 18 Minutes: My GreenPT Experiment Hit 10M Input Tokens

I’ve been trying to figure out how to make my AI usage less damaging to the environment. Most of my experiments so far have been about running local models on my MacBook, which uses way less power than an RTX card, or using small models like DeepSeek V4 Flash on OpenCode Go.

Then I found GreenPT. They host smaller models in data centers that run on renewable energy and use less water for cooling. I made an account, loaded €25, and started a session with GLM-5.2 — a much stronger model than the ones I’d been using. I wanted to see how far that €25 would go.

The session

One session. Eighteen minutes. A small JavaScript side project I’ve been messing with — and I asked GLM to verify its work by driving the Safari MCP browser tool. That means navigating localhost pages, reading rendered DOM, running JavaScript in the browser, taking screenshots, checking network requests — the works.

When I checked my balance after, €11 was gone. The provider said I’d sent 10 million input tokens.

No way, I thought. Ten million tokens in eighteen minutes on a tiny JS project? I dug into the data.

The math

OpenCode logs every session to a local SQLite database. I ran a query and it came back with 9,945,185 input tokens. The provider’s 10M claim was within 0.55%. They weren’t inflating.

But how? Let me walk through what actually happened.

Two things stacked

First, OpenCode dispatched the task to a sub-agent with a 284KB payload — full code diffs and task context, about 71,000 tokens. That got sent as part of every LLM call. 118 calls later, that single dispatch alone accounted for roughly 4 million tokens of base context repeated each round.

Second, GLM drove the Safari MCP extensively. The logs show 59 Safari tool invocations over the session:

• 28 safari_evaluate_javascript calls — running JS in the browser
• 11 page navigations
• 9 page interaction checks
• 4 safari_get_page_content calls — each returning full rendered DOM
• 2 network request logs
• 1 screenshot
• 1 console message dump

Every tool result came back as conversation history for the next LLM call. The per-call input started at 33,690 tokens and grew to 105,503 by the end of the tool-calling loop. That 72,000-token growth — about 5.7 million tokens total across all rounds — came almost entirely from tool results, and the Safari browser data was the bulk of it.

The caching question

This is where it gets interesting. OpenCode tracks cache usage per session. The GreenPT session logged tokens_cache_read: 0 — zero cached input tokens. Every request paid full price for the full history.

To test whether this was a GreenPT issue or just how things work, I compared it against another session I ran the same week using OpenCode Go’s hosted API with DeepSeek V4 Flash — same coding tool, same workload patterns, same tool-calling loop structure. The difference was dramatic:

Look at that. The OpenCode Go session processed more total tokens (6.9M vs 9.9M) and made more calls (80 vs 124), but only paid for 237k of them. Each subsequent call sent just the incremental delta — a few dozen or hundred tokens — instead of re-billing the full 38k+ context. The cache hit ratio was 96.6%.

GreenPT billed everything, every time, for both models I tried. The per-call input tokens tell the story:

OpenCode Go (cached):        GreenPT (no cache):
  43,632  (full context)       33,690  (full context)
   1,801  ← tiny delta         39,577  ← full history again
     136                        47,003
      73                        50,219
      43                        51,739
     108                         ... grows to 106k
     172

With caching, the 4M token cost from base context repetition drops to almost nothing. The tool result accumulation only bills for the new data each round, not the growing pile. That 18-minute GreenPT session could have cost €1-2 instead of €11.

Two possibilities:

1. GreenPT doesn’t support prompt caching for their models. Their API counts every token fresh every time.
2. OpenCode isn’t sending the right request structure to enable caching with GreenPT’s API.

Either way, the result is the same: no caching means every round-trip bills the full conversation history. And when you’re doing 59 Safari MCP calls that return rendered pages, network logs, and JavaScript results, that history gets expensive fast.

What’s next

I need to figure out whether caching is missing on GreenPT’s side or if OpenCode just isn’t wired up right for it. The comparison with OpenCode Go’s API proves caching works — the question is why it doesn’t with GreenPT.

Either way, the lesson is: if your provider doesn’t cache, tool-calling sessions get brutally expensive fast. An 18-minute session with Safari MCP verification can cost as much as a month of efficient local model use. Check your token logs before your credits disappear.