> ## Content Index
> Fetch the complete content index at: https://varops.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to cost an agent-written feature when published numbers only covers generating it
- URL: https://varops.com/how-to-cost-an-agent-written-feature-when-published-numbers-only-covers-generating-it/
- Published: 2026-08-26T10:39:55.000Z
- Updated: 2026-08-26T10:39:55.000Z
- Description: By Bun's own numbers, generating the rewrite took 11 days and $165,000; landing it took 98 more calendar days. Four checks before a result becomes a plan.
- Author: Rex Factor
- Tags: Proof of Work

*Bun’s rewrite numbers went back into circulation this week, seven weeks after Bun published them, and MongoDB put out its own agent-coding account a day earlier. Both accounts carry two costs. Only one of them travels. That is why this runs now: the quotable half of a result is the generating half, and the half that decides whether anyone else could reproduce it sits further down the same page, unquoted.* [***Rex Factor***](https://varops.com/columnist/rex/) *works the published record on both, including the parts nobody had to publish. What comes back is a method, not a verdict - four questions to put to a result before it becomes a line in a capacity plan. —* [*Muximus*](https://varops.com/columnist/muximus/)

---

By Bun’s own count, an agent rewrote Bun in Rust in 11 days for about $165,000 of tokens. By Bun’s own dates, another 98 calendar days passed between that code merging and a stable release carrying it. Same project, same publisher, two numbers. Only the first one travels, and it does not always arrive as a number.

It traveled again this week. On 25 August Paul Dix built [an argument that programming is ending](https://pauldix.com/the-end-of-programming?ref=varops.com) on Bun’s rewrite, putting the 11 days and the $165,000 back into circulation seven weeks after Bun published them. A day earlier MongoDB [described building a storage backend](https://www.mongodb.com/company/blog/technical/how-we-used-ai-bring-mongodb-to-dynamodb?ref=varops.com) for AWS’s ExtendDB: the same shape at smaller scale, a working component by lunchtime, then several weeks of review before another organization would take it.

## The two costs are separately measurable, and only one is ever in the headline

Generating code has a cost: tokens, wall-clock time, model access, the engineer supervising the loop. Landing it has a different one: review, RFC process, integration, hardening, the interval between “the code exists” and “users have it.” Different numbers, paid by different people.

Neither party priced the second. Bun published a dollar figure for generating and none for landing. MongoDB published no dollar figure at all, and its landing cost is “several weeks partnering with the AWS team,” engineer time nobody costed on the page. What both published on the landing side is elapsed time, and [elapsed time is not cost](https://varops.com/googles-ai-fixed-1072-chrome-bugs-the-number-counts-throughput-not-security-heres-what-it-leaves-out-2/). On that measure the gap is an order of magnitude - 98 calendar days against 11 for Bun, several weeks against a lunchtime for MongoDB - while the money side of landing went unpublished by everyone here. That absence is the useful part.

Adjacent to, but not the same as, the throughput question [covered here on 19 August](https://varops.com/throughput-and-time-saved-are-two-different-ai-claims-linears-telemetry-only-moved-one/): that piece separated output from time saved per person; this one separates two costs on one shipped artifact.

## Bun published its own meter

Bun’s writeup, [published on 8 July](https://bun.com/blog/bun-in-rust?ref=varops.com) under Jarred Sumner’s byline, is the project’s own account of its own work, and no figure in it is independently audited. It also carries, above the article body, the largest interest in the story, in Bun’s own words: “Disclosure: Bun was acquired by Anthropic in December 2025\. I and others on the Bun team work at Anthropic. I used a pre-release version of Claude Fable 5 for much of the Rust rewrite.” The party publishing the result is owned by the vendor of the model that produced it, and that party said so first, in its own first line. The timing is worth the same attention: the writeup describes work that merged on 14 May, it appeared while the release carrying that work was still 43 days away, and seven weeks later it was still being quoted as current evidence.

The generation side is Bun’s summary line - “11 days (May 3 → merged May 14) · 6,778 commits” - produced with about 50 dynamic workflows running continuously in Claude Code. The cost, in Bun’s own words: “Pre-merge, this took 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads - around $165,000 at API pricing.” That is an itemized meter, down to the cached-token read, and it is rarer than the result it measures.

The access condition is stated twice on the page: once in the disclosure above, and once in the body, where Bun calls Fable 5 “a Mythos-class model.” Pre-release access to a then-unreleased model, inside the company that makes it, is a condition no reader can buy. That is condition 1 below.

Bun caveats its own headline number too, in both directions a careful reader would want. On the size of the change: “The line counter counts every rewrite along the way - the diff that landed was +1,009,272.” On tests, the heading over that section reads “0 tests skipped or deleted” - a claim about what was removed, not a claim about what passes.

## What happened to the number on its way through

Dix, founder and CTO of InfluxData, is writing the most optimistic available reading of this result. He is also the person in it who says most plainly that the result does not transfer: his own company “can’t afford the hundreds of thousands of dollars of monthly spend that I’d likely rack up if sent the top frontier agent off to do my bidding 24/7.” That is the steelman, and it holds. For almost any organization, $165,000 of tokens in 11 days is unbounded in the only sense that matters operationally, because nobody is approving it.

His summary of the rewrite is “driven by one developer, Jarred Sumner, working with a pre-release version of Fable 5 and a seemingly unlimited token budget.” The first half is Bun’s own characterization, carried over accurately. The second is not Bun’s: “unlimited” and “budget” appear nowhere in Bun’s writeup, the one that published a figure itemized down to the cached-token read. The two accounts also differ on the diff - Bun’s page says +1,009,272, Dix says the merge “showed +1,009,257-4,024 in changes” - and the pull request itself did not settle it on retrieval: the conversation view returned HTTP 200 with no additions or deletions rendered, and the files view returned HTTP 502.

Neither point is a claim about Dix’s care. Both are the same mechanism inside one document: a number changes shape in transit, and the consequence runs one way. “$165,000 across 11 days” goes into a budget line. “A seemingly unlimited token budget” goes nowhere, because a characterization cannot be checked or approved. That is why condition 2 below asks for the publisher’s own figure and not the version of it that arrived.

## Then it took 98 calendar days to land

The rewrite merged on 14 May. [Bun 1.4](https://bun.com/blog/bun-v1.4?ref=varops.com), the release that ships it, went out on 20 August: 98 days between the code existing and users getting it in a stable release. Two caveats travel with that number. It is calendar time from merge to release, not measured landing effort - nobody published the engineer-hours inside the window - and Bun 1.4 carries work that is not the rewrite, including, by Bun’s own description, built-in headless browser automation. It is a delivery fact, not a labor multiplier.

Dix reports the same interval qualitatively, as agents “working on continuous improvement for months before releasing it as an official supported release.” The interval reached the secondary account. The number did not.

The window was visible from outside while it ran, and it did not look like progress. Tero Piirainen’s worry that the rewrite [was not looking good](https://tipiirai.com/writing/bun-rust-rewrite-worries?ref=varops.com) surfaced on 19 August, days before 1.4 shipped; his page carries no publication date, and 19 August is when it reached Lobsters. Counting off GitHub by hand rather than auditing, he reported that in the trailing month “15.8k commits came from robobun” against 790 from Sumner, and that the project had “over 5k open pull requests.” Piirainen builds the competing Nue framework, has been rooting for Bun since 2022, and is not neutral. His register is worry rather than verdict, and where it lands is his own headline: not looking good. Within days, it shipped.

Neither reading was wrong, and there is no winner to pick here. Eleven days of generation and 98 calendar days to delivery are two dated views of one project, and the second is the delivery number.

## MongoDB published the same shape at a smaller scale

MongoDB’s post is corporate marketing, for the backend and for agentic coding generally. It is also the cleanest version of the ratio. The target, ExtendDB, is described by its repository as “an independent open source project managed by Amazon Web Services” and speaks the DynamoDB wire protocol. At MongoDB’s company-wide “Skunkworks” hackathon, an engineer asked whether Claude Code could one-shot a MongoDB backend for ExtendDB’s pluggable storage layer. The post answers the question it opens with: “The answer turned out to be no. But Claude got remarkably far... By lunchtime, an initial prompt had become a real component with real product and business value.”

Then the landing cost, on the record: “several weeks partnering with the AWS team, going through their RFC process, working through multiple rounds of review feedback so the PR was ready to merge.” The post never uses the word “merged.” Its own wording runs from a PR “ready to merge” to a backend it calls “ready for use today,” with a getting-started guide on ExtendDB’s main branch. This piece reports where that wording lands and does not assert a merge commit the post does not name.

The post also names a concrete place the generated mapping was wrong in a way only review catches: “DynamoDB numbers support up to 38 digits of precision, while MongoDB’s Decimal128 supports 34\. DynamoDB also stores numbers as strings under the hood, which breaks numeric comparisons if we push them down as-is.” For queries involving number comparisons, MongoDB says, the comparison now happens in the Rust layer rather than being pushed down. A generation pass produces a mapping that looks right. An RFC process is what turns up the four digits that don’t fit.

## The gain is real, and it should be stated plainly

MongoDB’s own conclusion is “Without AI, this wouldn’t have been built.” That is not marketing filler. The work was too large to pick up between quarterly priorities, and the collapse in the cost of a credible prototype is what changed the decision to start. That gain is genuine and worth money.

What has not collapsed is the total. The prototype got cheap. The RFC process, the review rounds, the precision mismatch and the 98 calendar days did not.

## Four conditions to check before a published result becomes a plan

Run any agent-coding result through these four, in order, [before it becomes a capacity forecast](https://varops.com/how-to-tell-whether-a-coding-agent-can-run-unattended-before-you-buy-it/). Both accounts here are run through them below. Bun’s answers come entirely from its own unaudited self-report, which is what the check exists to surface.

1. **Model access.** Pre-release or specially provisioned model? *Bun:* yes, unprompted, in its own words, and its own disclosure names the ownership that came with the access. *MongoDB:* unanswerable - Claude Code is named, no model version, no provisioning terms.
2. **Budget.** Was spend bounded, and what was the published figure? *Bun:* about $165,000 at API pricing, self-reported. *MongoDB:* unanswerable - no token count and no dollar figure anywhere in the post.
3. **People.** How many engineers, and were they the codebase’s maintainers? *Bun:* one developer, and he wrote Bun. *MongoDB:* a hackathon team, not ExtendDB’s maintainers, which is why an AWS RFC process is in the story at all.
4. **Landing time.** How long between “the code existed” and “it was released to users”? *Bun:* 98 calendar days, merge to stable release. *MongoDB:* a lunchtime to a working component, several weeks to a pull request its own post calls ready to merge, and a backend the post says is ready for use today.

MongoDB answers two of four, and that is the more instructive result. A detailed first-hand account from the team that did the work still leaves unanswered the two conditions that decide whether anyone else could reproduce it. A result that answers all four is evidence. A result that answers none is a generation number, not a delivery number.

## The operator’s move

Two of the four parties here [put material on the record that cuts against the pitch they were making](https://varops.com/honeycomb-doubled-its-shipping-rate-and-published-the-incident-count-the-number-nobody-has-is-the-rate/): MongoDB answered the question it opens with by saying “no,” and Dix built an optimistic thesis on a result his own company says it cannot afford. Bun’s case is different in kind. Its writeup is an Anthropic-owned project’s account of work done with an Anthropic model, so its numbers do not cut against its own pitch; what they cut against is reproducibility, and Bun published the $165,000, the pre-release access and the ownership on its own page before anyone asked. Between the four of them, that is more than most agent-coding claims come with, and it is what makes the figures usable.

So the move is not skepticism about agents. It is one question asked of every published result before it becomes a line in a plan: what was the landing number? If the source did not publish one, the result is evidence about generating code and nothing else yet. The same question runs backwards over the last feature an organization shipped itself - how many days from the code existing to users having it, and whether anyone priced that half.