1. An AI search result invented a new cartoon character
A small website kept publishing articles with the help of AI. Some compared personalities with characters from Chiikawa, including Hachiware. When another AI was asked about the website's mascot, it confidently suggested that the name referred to a “troublesome Hachiware” from Chiikawa.
Who is that supposed to be?
The site's own character had apparently been recruited into somebody else's fictional world. No application. No interview. An AI simply hired it.
The only verified part of this anecdote is the answer that AI gave. We do not know whether it read the articles, guessed from the name, or made an unrelated association. Nor is there evidence here that the invented character exists in the official story. A fluent AI answer is not a verified fact.
2. Meanwhile, an article factory keeps working
The workflow writes an article, edits it for clarity, prepares twelve complete language versions, checks them, publishes them, and distributes links. When something breaks, another process diagnoses it, proposes a fix, checks the result, and tries again.
Soon the status reports acquire their own plot.
Agent A: “The publication problem is fixed.”
Agent B: “The checks have passed.”
Agent C: “I found a different reason publication stopped.”
Supervisor: “Assign another repair agent.”
Reader: “At this rate, the progress report will become a novel.”
Behind the joke is a serious distinction: saving a fix is not the same as verifying the live page. A content factory can become a repair factory too.
3. “Almost 1,900 articles?” First decide what counts
Five different numbers are often called “article count”:
- Original articles: distinct ideas or texts.
- Localized pages: language-specific versions of those articles.
- Prepared but unpublished: completed drafts still waiting for checks or publication.
- Published pages: items readers can actually open.
- Site routes: possibly including menus, application pages, and non-article paths.
For example, 1,000 originals fully published in twelve languages can create up to 12,000 localized article pages. That does not mean 12,000 independent ideas.
In one operating snapshot, the site recorded 15,862 routes. That was not a count of 15,862 Japanese articles. Claims such as “there are 1,900 articles” need a date, a unit, and a publication state before they can be compared. Adding every number together is how the reporting department develops a nervous twitch.
4. Then the GitHub repository reached about 2.46 GB
An anonymized GitHub repository reported 2,400,972 KiB, roughly 2.29 GiB or 2.46 GB in decimal units, in a snapshot dated October 8, 2026.
“Isn't an article just text?” you might ask.
A repository may also contain code, translations, publication indexes, validation records, media assets, and change history. But the reported number does not reveal which category used how much storage. That would require a separate size analysis. GitHub's reported repository size is also not necessarily the same as the size of a folder on a computer.
Article: “I'm only a few kilobytes.”
History: “I kept your previous versions.”
Translations: “We brought eleven friends.”
Storage: “Nobody told me.”
5. The answer: GitHub Free does not mean “5 GB total, then pay”
GitHub does not publish a single total-GB free allowance for all ordinary Git repository content, with automatic billing the moment that number is exceeded. Five gigabytes is a strong size recommendation, not a billing threshold.
GitHub says repositories should ideally remain below 1 GB, and strongly recommends remaining below 5 GB. Another official limits page recommends a maximum 10 GB on-disk size for the compressed Git storage. Ten gigabytes is not a guaranteed free allowance either.
A repository that causes excessive infrastructure or performance problems may be asked to change. So “free means an infinite warehouse” is as misleading as “the fifth gigabyte triggers a bill.” No universal GB billing threshold does not mean unlimited trouble-free use.
6. The real limits live in different drawers
| Resource | Practical limit or free allowance |
|---|---|
| Ordinary repository as a whole | No single total free-GB billing quota; ideally under 1 GB, strongly recommended under 5 GB |
| Git on-disk storage | Recommended maximum of 10 GB, not a paywall |
| One ordinary file | Warning above 50 MiB, blocked above 100 MiB; browser uploads limited to 25 MiB |
| One push | A 2 GiB limit |
| Git LFS for large files | GitHub Free includes 10 GiB storage and 10 GiB transfer allowance; separate from ordinary Git |
| GitHub Actions artifacts | GitHub Free includes 500 MB artifact storage; the usual included compute allowance is 2,000 minutes per month |
These are not the same pool of storage. When LFS or Actions usage goes beyond included amounts, the outcome depends on product-specific billing and budget settings. A normal repository of 2.46 GB does not automatically consume 2.46 GB of the Actions artifact quota. Conversely, being under 5 GB in ordinary Git does not mean every other meter is safe.
7. Why an article factory can grow faster than its article count
Git keeps not just the current files but a history of their changes. Updating a large index every hour might leave just one index visible in the latest version, while previous versions continue to exist in history. Add rewritten articles, refreshed translations, regenerated checks, and repeated output files, and storage growth stops matching the number of new articles.
There is an important qualification: Git compresses data and can pack similar versions efficiently. Editing a file once does not automatically double the repository's size. The major contributors must be measured.
Keep source articles and code in Git when version history matters. Consider storing frequently regenerated outputs and large media in a suitable system outside Git. This separates an editable source library from a warehouse of disposable results.
8. Congestion may break things before storage does
When several AI workers edit shared data nearly simultaneously, their writes can collide. One repair may succeed while another uses an outdated publication index. The article is ready, yet the public page stays unchanged.
It is premature to blame every failure on a full GitHub repository. File size, write frequency, concurrent updates, and publication consistency are separate questions.
Check four states in order: is the current source present; did it pass validation; was it deployed; and does the live page show the exact new content? Celebrate the fourth item, not just a cheerful report saying “fixed.”
9. Four ways to keep the free workflow healthy
Measure before deleting. Investigate large files and historical growth, not merely GitHub's headline size. GitHub also points to git-sizer as a diagnostic aid.
Keep disposable outputs in the right place. Large generated indexes, one-off logs, images, and audio do not always need permanent Git history.
Reduce pointless rewrites. Avoid rebuilding an enormous shared index after an unrelated change. Re-read the current state after a conflicting write and measure delivered results.
Treat history rewrites carefully. Deleting a file from the latest version may leave it in old commits. Rewriting shared history can break references and collaborators' copies. Check the impact and retain a safe copy before attempting it.
10. The count matters less than what reaches readers
Thousands of originals and tens of thousands of localized pages do not guarantee visitors. Can people find the pages? Are the facts correct? Does each language read naturally? Does each article contribute an observation rather than repeat a search result?
Google's public guidance favors useful, original, people-first content. Its policy on scaled content abuse addresses large quantities of low-value pages created primarily to manipulate rankings. Using AI is not the automatic offense; mass-producing pages without genuine reader value is the danger.
And the supposed “troublesome Hachiware”? That is a reminder to verify AI-generated claims before treating them as official lore. It is also a very good story about an AI accidentally writing fan fiction about a website's author.
Factory: “I'll increase the article count.”
GitHub: “I'll keep the history.”
Validator: “I'll catch the mistakes.”
Search AI: “I'll increase the character count.”
Everyone: “Not that kind of count!”
The takeaway: 5 GB is not GitHub's free-plan paywall. Storage, publication reliability, content quality, and AI assumptions each require a different check. Measure what readers can actually access and trust—not just what a factory has saved.
