Build it or borrow it?
How much code a 5-hour Claude allowance can write, and what that means for reusing someone else's brand-new GitHub repo instead of having Claude Code write your own.
Key takeaways
- A 5-hour window is worth roughly 1,500 lines of code on Pro and 7,700 on Max with Opus 5.5, and about 1.5× that with Sonnet 5.5. That's from my own Claude Code logs: lines of code written per dollar of API-equivalent usage, applied to measured plan sizes (~$12 of API value per Pro window [4], Max = 5× Pro [2]). Across my projects the rate varies about 4×, so read these as midpoints. Ultra has no 5-hour limit at all [1].
- Most of the allowance isn't the code itself. Each line of code written cost about output tokens, while a line is only ~10 tokens long. Reading context, thinking, running commands and explaining take the rest.
- Most new repos fit in a single window. One Pro window on Opus (~1,500 lines) could write of the 2026 repos that have code, and one Max window (~7,700 lines) . With Sonnet it's and . The median new 2026 repo (~1,050 lines) costs about two-thirds of a Pro window, so for most of them "borrowing" saves very little.
- New repos are rarely tested or licensed. Of 2026 repos with code, have any test files, have CI, have a license file, and about 6% have even one star. Without a license you aren't allowed to reuse the code at all [10]. Repos built with AI agents are tested more often ( vs ).
- Generated code isn't automatically safe either. AI-written code passes security checks only ~56% of the time [8], and models invent package names 5–22% of the time [9]. What makes your own version worth it is that you can read, test and own it.
- Rule of thumb: borrow established, maintained libraries for hard or security-critical problems. For a small, new, untested repo, have Claude Code write your own tailored version, with tests, and use the repo as a reference if its license allows.
How the limits work
Claude's paid plans meter usage in two layers: a rolling 5-hour session limit and a weekly limit, shared between the Claude apps and Claude Code [3]. Anthropic publishes them as multiples of Pro, not as token counts [2]:
| Plan | Price | 5-hour limit | Weekly limit | API value per 5 h (measured) |
|---|---|---|---|---|
| Pro | $20/mo | 1× | 1× | ~$12 [4] |
| Max | $100/mo | 5× Pro | 5× Pro | ~$60 (5 × Pro) |
| Ultra | $200/mo | None (verified accounts) | 10× Pro (~$1,550/week) | Not capped per window |
To turn "1× Pro" into something countable, I use a third-party measurement: Wokey prices real subscription traffic at official API rates and found that a Pro week is worth about $155 of API usage, or roughly $12 per 5-hour window, and the old Max 20x (now Ultra) about $1,549 per week [4]. API rates are $4 / $20 per million input / output tokens for Opus 5.5 and $2 / $10 for Sonnet 5.5, with cache reads at $0.20 and $0.10 [1].
Assumption: I treat the limits as roughly proportional to API cost, so Sonnet's half price buys about twice the tokens. Anthropic doesn't publish how each model counts against the limit, and Wokey reports Opus 5.5 using about 0.6× the limit of earlier Opus models per token [4], so the true Sonnet-to-Opus ratio could be smaller.
Lines of code per 5-hour window
The conversion from dollars to lines comes from my own Claude Code logs: , model responses across all my projects, almost all on Opus 5.5. Every Write and Edit call records the text written, so I counted non-blank lines written into code files (the same extensions as the repo study, so Markdown, JSON and other data don't count) and priced every response's tokens at API rates.
| Plan (API value per window) | Opus 5.5 | Opus range | Sonnet 5.5 | Sonnet range |
|---|
Opus = window value × my lines-per-dollar (overall, and the lowest and highest project with at least $5 of usage). Sonnet = twice the tokens per dollar, divided by a token-efficiency factor of 1.0–1.6 (Sonnet tends to need more tokens per task at high effort; one hands-on comparison still found it 42% cheaper per run [6]). Lines are counted each time they're written, so a file rewritten twice counts twice.
Ultra has no 5-hour cap, so the window isn't the limit; the weekly cap is about $1,550 of usage, or roughly lines of Opus code a week. In practice the limit is how fast one person can drive the work: my busiest real 5-hour block used of API value, and the most code written in one block was lines.
11 of my 52 blocks went past what a Pro window allows, and none came near a Max window. Lines of code rise roughly in step with usage, at about 130 lines per dollar. That matches the logs: they contain no "usage limit reached" message at all.
How many new repos fit in one window?
Putting the two studies together: take each window's line estimate and ask what share of repos created in 2026 are no bigger than that. Repo size is the same measure as the size-trend study, GitHub's language byte counts divided by 41 bytes per line [11], for the sampled 2026 repos that contain any code (about two-thirds of all new repos; the rest are empty, docs, notebooks or data).
| One 5-hour window | Lines (midpoint) | 2026 repos that fit | Range | 2025 | 2024 | 2020 |
|---|
"Range" uses the low and high ends of the line estimate (my least and most productive projects). Sampling error on the 2026 midpoints is about ±1 point. Ultra has no 5-hour cap, so its row is one week.
The bigger 2026 repos shift this down: a Pro window would have covered of 2024's new repos but only of 2026's, because the median 2026 repo with code is about three times the size of 2024's (~1,050 vs ~330 lines). Still, more than half of what people publish today is small enough for one Pro window, and more than four in five for one Max window. The repos that don't fit are the ones most worth borrowing anyway: in 2026, of repos over 10,000 lines have tests, against under 1,000 (see below).
Read this as "comparable effort", not "could rebuild exactly". A repo's line count is what survived, while the window estimate counts every line written, including rewrites, so producing a finished repo of a given size usually takes more than that size in written lines. Repos also include generated, copied or vendored code that nobody typed. Both effects make the real share somewhat lower than shown, closer to the low end of the range.
Where the tokens go
A line of code averages ~41 bytes (from the earlier calibration study [11]), which is roughly 10–12 tokens. Yet each line written cost about output tokens and a lot of input. The code in the files is only about a tenth of what the model writes. The rest is reasoning, tool calls, commands, and replies to me, plus re-reading the conversation and files on every step:
Productivity per dollar varied about 4× between projects: from lines per dollar on projects with a lot of investigation and debugging, to on projects where Claude mostly wrote new files. Greenfield code is the cheap case, so a small tool written from scratch sits near the high end.
| Project | Code lines written | API value | Lines per $ | Output tokens per line |
|---|
What about Codex?
OpenAI meters Codex differently. On Plus (and standard Business) the 5-hour allowance is given as an estimated number of local messages, per model: for example 15–160 for GPT-6.1 Sol, 5–45 for GPT-6 Astra and 350–3,000 for the small GPT-6 Luna. Cloud tasks draw more from the same pool, and the Pro tiers ($100, $200, $500) currently have no 5-hour limit, only weekly ones [7].
A message isn't a fixed amount of work, so this can't be converted to lines as directly. As a rough guide, my Claude Code prompts averaged lines of code each, so 15–160 GPT-6.1 Sol messages would be somewhere around lines per window on Plus, the same ballpark as Claude Pro. Treat this as an order of magnitude, not a comparison: the models, prompting styles and how much each message does all differ.
How tested are new repos?
To check how tested new repos really are, I read the full file tree of every repo with code in the age-matched subsample from the earlier study ( repos created in 2020, 2024, 2025 and 2026) and looked for test files (e.g. tests/, *_test.py, *.spec.ts, src/test/), CI configuration (GitHub Actions, GitLab CI and others), a license file, and dependency lockfiles.
| Repos with code | Repos | Any tests | CI | Tests and CI | License | Lockfile |
|---|
Test files are detected by path and name, so a repo with tests in an unusual place is missed, and an empty tests/ folder with one file counts. "Lockfile" means a pinned dependency file such as package-lock.json or poetry.lock.
Small repos, the kind you'd most likely find and want to borrow, are the least tested: in 2026, of repos under 1,000 lines have any test file and have a license. Only 6.2% of all 2026 repos have even one star [11], so for most of them nobody else has tried the code either.
One twist: repos with an AI-agent trace are much more likely to be tested ( have tests and have CI, against and without a trace). Agents tend to write tests when asked to build something, which is a point in favour of generating your own with Claude Code, provided you ask for tests too.
Risks on both sides
Borrowing a new repo
- Unknown quality. Three in four new repos have no tests at all, and almost none have users.
- No license, no right to reuse. Without a license, default copyright applies and nobody may copy, modify or redistribute the code [10]. Under 15% of new repos have one.
- Supply-chain attacks are common. Sonatype logged 149,329 malicious open-source packages in Q3 2026 alone, most of them on npm and built to steal secrets or drop malware [5]. A random repo's install script runs on your machine.
- It fits someone else's problem. You inherit their assumptions, and extra code you don't need.
- Abandonment. 59% of 2026 repos with code had their last push within a day of being created (from the earlier study), so bugs won't be fixed upstream.
Generating your own
- Security gaps. Across 100+ models, AI-generated code passed Veracode's security tests only ~56% of the time in 2026, barely up from 55% a year earlier; cross-site scripting passed just 15% [8].
- Invented dependencies. Code-generating models recommend packages that don't exist: at least 5.2% of the time for commercial models and 21.7% for open-source ones, often repeatably, so attackers can register those names [9].
- Maintenance is yours. Every line you generate is a line you own, debug and update.
- It's untested unless you ask. Generated code is "yours", but only becomes trustworthy once it has tests you've seen run.
- It costs allowance. Small, but real: ~0.6 Pro windows per 1,000 lines of new code.
Borrow or build?
The economics have shifted: writing 1,000 lines of tailored code now costs about $8 of API value, which is two-thirds of a Pro window or an eighth of a Max window. Reading and auditing someone else's 1,000-line repo properly costs about as much attention, often more. So for small code the default should flip from "find a repo" to "generate my own", and borrowing should be kept for code whose value comes from many people having used and fixed it.
| Situation | Better choice | Why |
|---|---|---|
| Small tool, script, glue code, UI for your own workflow (under a few thousand lines) | Build with Claude Code | Fits in one window or less, is tailored to you, and you can ask for tests. A random repo of that size is usually untested and unlicensed. |
| Security-critical or standards-heavy: auth, crypto, parsing, payments, date/time, network protocols | Borrow an established library | The value is in years of edge cases and bug reports, which no single session reproduces. Generated security code fails often [8]. |
| Big, mature project (many stars and dependents, regular releases, tests and CI, a license) | Borrow | Others have already tested it in production; maintenance is shared. |
| New repo that does almost what you want, with a permissive license | Use it as a reference | Have Claude Code read it and write your version, keeping the ideas and the attribution the license asks for, and add tests. |
| New repo with no license | Don't copy it | You have no right to reuse the code [10]. Write your own from the idea, or ask the author for a license. |
| Anything that pulls in dependencies | Check every package | Whether borrowed or generated: confirm packages exist, are the ones you meant, and are maintained [5] [9]. |
Quick checks before borrowing a repo: a license file; tests and CI that actually run; more than one contributor or some outside users (stars, forks, dependents, issues being answered); commits after the first week; and a dependency list you recognise. In my sample, under 10% of 2026 repos with code pass even the first two.
Limitations
- One person's logs. The lines-per-dollar rate comes from about six weeks of my own sessions, a mix of research, data work and app code. Other people's work, prompting styles and projects will give different rates; across my projects alone it varied about 4×.
- Almost no Sonnet data. Nearly all my usage was Opus 5.5, so the Sonnet figures scale Opus by price and a token-efficiency assumption rather than measuring it.
- Plan sizes are third-party measurements. Anthropic doesn't publish token or dollar figures for its limits. The $12-per-Pro-window figure is Wokey's measurement for the week of 26 October 2026 [4], and limits change: Anthropic raised the 5-hour limits when Opus 5.5 launched, without publishing figures.
- Cache pricing is approximate. Cache writes were priced at the 5-minute rate. Claude Code also uses longer-lived cache entries, which cost more, so the true API value per line may be somewhat higher.
- "Lines written" counts writes, not surviving code. A file rewritten three times counts three times, and code later deleted still counts.
- "Fits in a window" compares written lines to surviving lines. Repo sizes are final line counts (including generated or vendored code), while window estimates count every line written, so the real share of repos one window could produce is somewhat below the midpoint.
- Codex isn't measured. The Codex figure multiplies OpenAI's message estimates by my Claude lines per prompt; it shows a ballpark, not a comparison.
- Test detection is heuristic, and "has test files" doesn't mean the tests pass or cover much. The subsample has about 400–570 repos with code per year, so shares are ±2–4 points.
Sources
- Pricing, Anthropic (claude.com): API prices per model and plan descriptions (Pro, Max, Ultra). Accessed 2026-11-03.
- What is the Max plan?, Claude Help Center: 5× Pro usage per 5 hours and per week. Accessed 2026-11-03.
- Use Claude Code with your Pro, Max, or Ultra plan, Claude Help Center: session and weekly limits, shared with Claude apps. Accessed 2026-11-03.
- Claude Usage Limits (November 2026): Pro & Max Weekly Limits, Measured, Wokey: API value of subscription limits, measured on real accounts; data updated 2026-11-02. Third-party.
- Q3 2026 Open Source Malware Index: When Compromise Compounds, Sonatype, 2026-10-08.
- Claude Sonnet 5.5 vs. Opus 5.5: 42% cheaper and perfect on every run, The New Stack, 2026. One hands-on comparison; other tests found Opus cheaper per outcome on harder work.
- ChatGPT Work and Codex pricing, OpenAI: local messages per 5 hours by model, Pro tiers without a 5-hour limit. Accessed 2026-11-03.
- 2026 GenAI Code Security Report, Veracode, July 2026: 56% average security pass rate across 100+ models.
- We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, Spracklen et al., USENIX Security 2025.
- Licensing a repository, GitHub Docs: without a license, default copyright laws apply. Accessed 2026-11-03.
- Primary data: this research's LOC calibration and repo size trend studies (random samples of 170,000 repos, age-matched subsample of 4,245), the tests/CI scan, and my local Claude Code logs, collected 2026-11-02/03.