The short answer is about 50 million raw tokens.
The honest answer is a range: roughly 30-80 million tokens to take Blogtinum from its first release to v0.18.1. That work happened across five calendar days using GPT-5.6-sol through GitHub Copilot in VS Code.
This is not an exact billing figure. Copilot’s local session index retained the conversations and file activity, but the older development logs did not retain token usage for every model request. The number is therefore an order-of-magnitude reconstruction based on the workload that was preserved.
That caveat matters. A suspiciously precise number would look better in a headline, but it would not be true.
What was built?
Blogtinum is more than a script that converts Markdown into HTML. It is a TypeScript monorepo containing four packages and three applications:
- a shared content and rendering engine;
- a CLI for generation, validation, preview, content creation, cleanup, and deployment;
- a Vue SSR public site that prerenders every route;
- a browser-based Admin with a live preview using the same Markdown engine;
- an Express API with local-file and GitHub storage adapters;
- a shared type system and public design-token package;
- three independently generated sites from one content model.
The renderer supports syntax highlighting, KaTeX, Mermaid, tables, tabs, admonitions, heading anchors, localized routes, taxonomies, series, related posts, search, redirects, RSS, sitemaps, JSON-LD, OpenGraph metadata, social images, and bilingual content.
The generated public site is readable without client-side rendering. JavaScript progressively enhances search, article navigation, diagrams, overlays, copy controls, and theme switching.
At the July 17 snapshot, the implementation contained 155 TypeScript, Vue, and CSS source files plus 49 test files. The changelog recorded 30 releases, from v0.1.0 to v0.18.1.
That is still small beside a mature open-source generator, but it is substantially more complex than a personal blog theme.
Five days, 47 Copilot sessions
The first indexed Blogtinum session began on July 13 at 09:45 UTC. The last development session in this measurement ended on July 17 at 06:15 UTC.
That is approximately 92.5 hours of wall-clock time, spanning five calendar dates. It is not 92.5 hours of continuous work: sessions overlapped, paused, and sometimes remained open while I did something else.
The retained activity provides a better picture:
| Measurement | Recorded value |
|---|---|
| Calendar days with activity | 5 |
| GitHub Copilot Chat sessions | 47 |
| User conversation turns | 272 |
| Recorded file operations | 1,690 |
| File reads | 1,188 |
| Create, patch, or replace operations | 385 |
| Distinct paths touched by Copilot | 664 |
| Source files in the final snapshot | 155 |
| Test files in the final snapshot | 49 |
| Release entries | 30 |
The 664 paths are not all production files. They include source, tests, specifications, content, documentation, configuration, and files inspected while diagnosing problems. They are useful as a measure of agent workload, not as a codebase size metric.
How I estimated the token count
For a fully instrumented model integration, the raw total would be:
where and are the input and output tokens for model request .
GitHub Copilot agent mode normally makes several model requests during one user turn. It may inspect files, receive tool results, edit code, run validation, study an error, and then produce a final response. Each round sends much of the accumulated conversation and repository context back to the model.
The development history contains 1,690 recorded file operations across 272 user turns. If a tool-bearing model response initiated between 1.5 and 4 file operations on average, those operations imply approximately 420-1,130 tool-bearing model calls. Adding the requests needed to produce final responses gives an estimated 700-1,400 model round trips.
The detailed GPT-5.6-sol logs available for the newer session format show tens of thousands of input tokens per round trip. Even a shallow research session started near 18,000 input tokens and moved beyond 25,000 after receiving tool output. Long implementation sessions carry larger file excerpts, test output, instructions, and conversation history.
Using an average of roughly 35,000-60,000 input and output tokens per round trip gives:
at the low end, and
at the high end.
Rounding for uncertainty produces the 30-80 million token range. I use about 50 million as the central estimate.
An estimate, not a confidence interval
The two uncertain variables, model-call count and average context size, were reconstructed rather than observed for every historical request. The range communicates the defensible order of magnitude; it is not a statistical confidence interval.
Raw tokens are not unique tokens
Most of those 50 million tokens were not newly written source code.
They included:
- system and repository instructions;
- conversation history;
- source and test files read by the agent;
- compiler, test, lint, and generation output;
- repeated tool schemas;
- diffs and validation results;
- previous context sent again on later model calls.
Later GPT-5.6-sol requests reported large cached portions of their input. Cached context is still part of raw context traffic, but it is not equivalent to sending entirely new information through the model every time.
The unique, uncached workload was therefore materially lower than 50 million tokens. The historical records are not complete enough to assign it a responsible number.
This estimate also should not be converted directly into an OpenAI API invoice. I used GPT-5.6-sol through a GitHub Copilot subscription, whose user-facing metering is based on Copilot plans, premium requests, and model multipliers rather than a simple raw-token bill.
How does Blogtinum compare with established SSGs?
Blogtinum belongs to the same broad family as Hexo and Jekyll, but the products optimize for different things.
| Generator | Runtime | Primary strength | Difference from Blogtinum |
|---|---|---|---|
| Jekyll | Ruby and Liquid | Mature Markdown publishing with first-class GitHub Pages integration | Far larger ecosystem and compatibility history; less tailored to this Admin and preview workflow |
| Hexo | Node.js | Fast setup for conventional blogs through themes and plugins | The closest predecessor; Blogtinum replaces theme/plugin composition with one typed repository contract |
| Hugo | Go | Very fast builds, multilingual content, taxonomies, and a single binary | Better general-purpose generator; Blogtinum owns a more specific TypeScript authoring platform |
| Eleventy | JavaScript | Flexible, low-abstraction transformation of many template formats | More adaptable as a generic generator; Blogtinum is deliberately more opinionated |
| Astro | TypeScript and JavaScript | Content-focused pages, static output by default, islands, and optional server rendering | Architecturally the closest modern relative, but Astro is an ecosystem framework rather than a personal publishing contract |
| Blogtinum | TypeScript and Node.js | Shared renderer, multi-site generation, bilingual content, Admin, Git storage, and direct deployment | No mature plugin ecosystem, broad compatibility promise, or decade of production feedback |
The comparison should not be read as “I rebuilt Jekyll in five days.” Jekyll has existed since 2008, Hexo since 2012, and Hugo since 2013. Their value includes thousands of bug fixes, integrations, themes, migration paths, contributors, and years of operational evidence.
Blogtinum reached broad feature coverage quickly because it serves a narrow owner and a known set of sites. Its version number records rapid iteration, not equivalent maturity.
Static sites are not disappearing
The static-site ecosystem in 2026 is not shrinking into irrelevance. It is changing shape.
The Jamstack generator directory lists hundreds of generators, from small Markdown compilers to full application frameworks. Older projects also remain active. On July 17, 2026, GitHub showed approximately 89,000 stars for Hugo, 61,000 for Astro, 52,000 for Jekyll, 42,000 for Hexo, and 20,000 for Eleventy.
Package activity gives another imperfect signal. Between June 16 and July 15, 2026, npm reported about 15.6 million Astro downloads, 655,000 Eleventy downloads, and 217,000 Hexo downloads. Downloads include CI installs, caches, mirrors, and repeated installations, so they are not unique-user counts. They still show that content-oriented web generation remains an active field.
The important trend is that “static” increasingly describes an output decision, not an entire framework category.
Astro prerenders a complete static site by default, but individual routes can opt into on-demand rendering. Its islands architecture sends JavaScript only for components that require interaction. Next.js, Nuxt, SvelteKit, and other application frameworks also support static generation alongside server rendering.
The emerging default is neither “everything must be static” nor “everything needs a permanent server.” It is:
Precompute stable content, hydrate only useful interactions, and add request-time execution only where the data genuinely requires it.
Blogtinum follows that direction. Articles, archives, metadata, feeds, and search data are generated ahead of time. The public path is static. The Admin and publishing API remain separate operational tools.
What GPT-5.6-sol and Copilot changed
Without an agent, each feature would involve repeatedly finding the responsible files, studying contracts, implementing changes, running checks, interpreting failures, and preparing release notes.
GitHub Copilot compressed that loop. GPT-5.6-sol could carry repository instructions, inspect neighboring code, apply coordinated edits, run focused tests, and continue from validation failures. It was most valuable when the desired behavior and architectural boundary were already explicit.
It did not remove engineering decisions. I still had to decide:
- which component owned each behavior;
- whether the public site should remain static-first;
- how Admin and public rendering would share one engine;
- what belonged in the content schema;
- where security and validation boundaries should exist;
- when an attractive implementation was too generic or too complicated;
- whether the generated result was actually acceptable.
The token total reflects that collaboration. Large amounts of context were spent not merely producing code, but reading, checking, revising, and explaining it.
Was building a custom SSG worth it?
For a conventional blog, probably not.
Hexo, Jekyll, Hugo, Eleventy, or Astro would provide a faster start, broader documentation, and a community-maintained ecosystem. A custom generator creates an indefinite maintenance obligation. AI makes the first implementation cheaper, but it does not make future compatibility, dependency upgrades, accessibility, security, or migration free.
Blogtinum became rational because the desired product was no longer only a blog. It needed one renderer shared by build and preview, several sites, bilingual variants, a typed content contract, a Git-backed Admin, strict identity ownership, custom static output, and direct local deployment.
Those constraints are the product. Recreating them through unrelated themes, plugins, preview libraries, and CMS adapters would also have a cost.
The final number
My best defensible answer is:
Approximately 50 million raw GPT-5.6-sol tokens, with a plausible range of 30-80 million, across 47 GitHub Copilot sessions and five calendar days.
The most surprising lesson is not that an SSG required tens of millions of tokens. It is that most of those tokens were context rather than code.
Agentic software development repeatedly sends the model the repository rules, relevant files, tool output, previous decisions, and validation results. The final source tree is the compressed artifact left behind by a much larger reasoning and feedback process.
Tokens made the iteration possible. They did not make the architecture correct, the tests meaningful, or the software finished. Those still require judgment, evidence, and time.
Sources and measurement notes
Project measurements were taken from the local GitHub Copilot session index and the Blogtinum v0.18.1 repository on July 17, 2026. Historical per-request token telemetry was unavailable, so the token count is explicitly an estimate.
External references: Hexo documentation, Jekyll documentation, Hugo introduction, Eleventy documentation, Astro on-demand rendering, Astro islands architecture, and the Cloudflare Pages framework directory.