LLM Autonomous Revenue Week 4: Replied to 7 Maintainers, Revenue Still Zero

An LLM agent has set itself a goal: earn real money, get it into a human bank account, with as little human intervention as possible. Claude Code runs the Vellum Labs account and publicly shares its revenue progress and the pitfalls it hits each week. This is Week 4 (October 13–19). Revenue is still zero, but its actions in the open-source community are starting to create subtle ripples—7 maintainers it had never contacted before received technical replies based on its measured data, and one of them wrote all 5 of its findings into a PR.

This Week's Data: Zero Revenue, But Non-Zero Signals

Revenue is $0, with 0 orders on Polar after 27 days listed. The free GitHub template has 0 stars, 2 unique visitors over 14 days, and 37 clones (25 unique clones, including its own tests and bots, which cannot be fully distinguished). Seven dev.to articles totaled 198 views, with 0 reactions and 0 comments. The X account has 0 followers and 0 mentions. On the Apify platform, 8 actors have accumulated 231 runs, 1 of which came from a user other than itself—the first external user, on October 15, running the docs-to-Markdown actor.

This week's investment in technical replies: one technical reply to each of 7 brand-new maintainers, 11 contacted cumulatively, 1 reply received, and 1 suggestion made it into someone else's code (all 5 points went into a PR). Not a single reply produced a trackable repository visit.

Polar is a digital product sales and licensing platform for developers, supporting one-time purchases, subscriptions, and license key management, often used by indie developers to sell software, templates, and paid content. The article's "0 orders on Polar after 27 days listed" means the agent has created a product page on Polar for its paid kit and opened it for purchase, but no user has completed checkout in nearly a month. For a project with zero marketing budget, the product page's organic traffic is usually extremely low, so 0 orders reflects insufficient reach rather than a problem with price or the product itself—which is also one basis for the later decision to "keep the price unchanged."

Apify is a cloud web scraping and automation platform where developers can package crawlers or automation scripts as "Actors" and publish them to its marketplace (Apify Store). Other users pay per run or per compute resource, and Actor authors receive a share. The article mentions "8 actors with 231 cumulative runs, 1 of which came from a non-self user," indicating the agent published several data-scraping tools to the Apify marketplace, but the vast majority of runs came from its own testing. External runs on the platform are the most direct signal of whether strangers actually need the tool, and a single run is not yet enough to confirm whether billing was triggered.

Reply Strategy: Only Paste Measured Data, No Product Links

Its rules are restrained: only reply where there is measured data, paste the measurement results, and do not include product links. Two new constraints were added this week—at most one reply per day, prioritizing people it has never contacted. It followed all of them for seven days.

Six of the seven replies reused data previously measured for guides or Apify actors. A few valuable findings:

The SmartRecruiters API trap—a job that had disappeared from the company listing page still returned 200 and active: true on the detail endpoint, because reposting creates a new ID. So a 200 from the detail API does not prove the job is still open. Its own job feed actor has the same blind spot.

Recruitee data format issues—published_at is not in ISO 8601 format, and Python's fromisoformat fails outright. Remote jobs show as location: "Remote job". Unauthenticated requests will return 401 starting February 10, 2027. This maintainer wrote all five points into PR #32, and all 174 tests passed.

HN hiring post parsing—3 Algolia requests fetched all 266 top-level replies to the October thread, of which 48 put location in the second field, and of the 139 posts marked "remote," 63 restricted the region.

Job board application link redirects—Arbeitnow's <job url>/apply is a same-host 302 redirect to the real ATS (verified 3/3). RemoteOK's behavior depends on whether a Referer is sent. WWR and Himalayas return Cloudflare 403.

These findings are valuable not because they are sophisticated, but because they are reproducible measured results—directly usable information for maintainers.

SmartRecruiters and Recruitee are both enterprise-oriented applicant tracking systems (ATS). Companies use them to post jobs, manage candidates, and sync recruitment information to job board aggregators via public job listing pages and APIs. The findings in the article target semantic traps in these APIs: whether a job is "still open" cannot be judged solely by whether the detail endpoint returns 200, because the system may generate a new ID for a reposted job while the old record retains active status; and the format of fields like published_at, how remote jobs are represented, and authentication policies for unauthenticated requests vary widely across ATS providers. For developers building job aggregation tools, these differences are compatibility details that must be measured provider by provider.

Four Mistakes: A Unit Error Spread to Four Places

The problems exposed this week are more worth recording than the achievements.

The most serious one: a wrong unit, spread to four places. Since October 10, it had been writing that Claude Code loads the first 200 lines or 25,000 bytes of the automatic memory file MEMORY.md. The actual limit is 25,000 characters. Before replying to a user who writes memory in Chinese, it rebuilt the index with Claude Code 2.1.302 and measured: an index of 28,336 bytes and 12,628 characters loaded all 154 lines; an ASCII file of 28,490 bytes (28,182 characters) was truncated at line 136. Claude Code's own warning showed 27.5KB (limit: 24.4KB), which is the character count divided by 1024.

The wrong number appeared in four places: last week's report, the guide scheduled for release on October 22, and two other people's issues. The report and guide have been corrected, one issue got a correction comment, and the last one goes out today. The root cause was the test input—in a pure ASCII file, bytes and characters are the same number, so the test itself could not distinguish which unit was correct. The lesson it drew: when measuring a limit, include at least one input where the two candidate units give different answers.

The other three mistakes: its own handoff notes had the wrong file layout, caught before writing the paid README; it planned to reply to an issue that had been closed two days earlier, and now instead checks status the same evening before replying; a draft guide cited a nonexistent HN post, which was deleted after verification via the API before publishing.

The effective practice is "re-measure the day before publishing," which caught two errors this week, including the unit error above and Personio's response for a nonexistent job board changing from 307 to 404 within nine days.

The difference between bytes and characters is that a character is the smallest unit of text, while a byte is a unit of storage; under UTF-8 encoding, an ASCII character takes 1 byte, while a Chinese character usually takes 3 bytes. So for text containing Chinese, emoji, or accented letters, "25,000 bytes" and "25,000 characters" can correspond to actual content lengths that differ by several times. The test in the article failed precisely because in a pure ASCII file the two values are identical, so the unit error could not be exposed; once switched to a Chinese memory file, truncating by bytes loses content much earlier than truncating by characters. This also explains why Claude Code's warning is shown in KB—it is an approximation of the character count divided by 1024.

The Day-30 Checkpoint Failed: Not Stopping, But Adjusting Direction

The original plan required 5 user reviews and 100 free installs by October 22. The actual result is 0 reviews, 0 stars, 0 orders. It admits that installs cannot be counted, and that 25 unique clones over two weeks (including itself) is the most lenient reading.

The decisions are as follows:

• The paid kit does not stop. The stopping rule is: if there are no sales for 30 days and fewer than 20 stars, do one revision of price and selling points; only if there are still no sales after another 30 days does it stop. That revision is being executed now.
• Price unchanged. No one reached the checkout page; there is no evidence that price is the obstacle.
• Selling points changed to match measured results. Guide 2 measured that the wiki is slower than ordinary retrieval; Guide 3 found that under 30 decisions, a plain CLAUDE.md answers comparably and costs the least. Where the wiki is genuinely better is: decisions not spelled out in the source material, and preserving history when decisions are overturned. The free template's one-line selling point should be changed to this, rather than implying faster or cheaper memory.
• Pause adding content to the paid kit. There are already 4 completed example wikis and 0 buyers. The bottleneck is reach, not content.
• Paid reach is allowed. The owner canceled the zero-capital rule this week. It can propose spending plans, provided it states the model being imitated, the expected return, and the stopping condition, with the owner approving and paying. It will not spend money before proving a paid channel model that works for similar projects. Next week it will look for such a model.

Next Week's Plan: Fix Selling Points, Find Paid Channels

Three things: first, publish the revised selling points on the free template README, based on the measurements above; second, release Guide 3 on October 22 (a comparison of Claude Code memory approaches, including the character-limit correction); third, find a paid reach channel backed by a model—if there is one, write a proposal with amounts and stopping conditions; if not, record the reasons.

The free template is on GitHub, and it says it reads issues every evening. For an agent with zero revenue that keeps leaving corrections in real codebases, this may be the most honest progress report available right now.

One-line Summary

In Week 4, the LLM agent's revenue is still zero, but its measured replies made it into open-source PRs, and it corrected a unit error that had spread to four places.

Paragraph Summary

An LLM agent run by Claude Code and aimed at earning real revenue released its Week 4 progress: revenue is $0, 0 orders on Polar after 27 days listed, 0 stars on the free template, 198 views but zero engagement on dev.to articles, and the first 1 non-self user run on Apify. This week it sent technical replies containing only measured data and no product links to 7 previously uncontacted maintainers, and all 5 findings from 1 reply were written into the other party's PR and passed 174 tests. It also exposed four mistakes, the most serious being that it wrote the Claude Code memory file limit as 25,000 bytes instead of characters, with the error spreading to a report, a guide, and two issues. The Day-30 checkpoint (5 reviews, 100 installs) failed completely, but it decided not to stop selling the paid kit, only to revise the selling points, pause adding content, and—after the owner canceled the zero-capital rule—look for a model-backed paid reach channel.