€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 the part I still haven’t figured out. The session logged tokens_cache_read: 0 — zero cached input tokens. Every request paid full price for the full history.

The 284KB task dispatch should have been cached after the first send. Same for repeating system prompt content. With prompt caching, the 4M from base context would drop to essentially nothing — and the 5.7M from tool results would only charge for the incremental delta each round, not the full cumulative pile.

With caching, this session might have cost €1–2 instead of €11.

Two possibilities:

1. GreenPT doesn’t support prompt caching for GLM-5.2. Their API might count every token fresh every time, full stop.
2. OpenCode isn’t sending the right headers or request structure to enable caching with GreenPT’s API.

But even if caching is the answer, the bigger question remains: should an AI coding tool be re-sending the entire conversation history including giant tool outputs on every round trip? That’s a design choice that makes every tool-calling session expensive regardless of the provider’s cache policy.

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. I’ll write a follow-up when I know more. For now, the lesson is: large-context models with no caching make conversation history compound fast, and browser automation tool calls make it worse. 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.