Maintain a forked open-source app through eight releases with Claude

Artur Shaikhutdinov had Claude Opus 5.5 maintain his OpenResearch fork for three weeks: 8 releases, 33 commits and 28 new tests in about 11 hours of agent time, for $32.

Done withClaudeinGitHub· Oct 16, 2026

What they did

Artur Shaikhutdinov had earlier forked OpenResearch with Claude to add three coding agents, Kimi Code, MiniMax Code and ZCode. After a reader reported that ZCode failed with a model selection error, he kept Claude Opus 5.5 on the fork for three weeks. Claude worked in a cloud Linux container while he installed each CI build on his Windows 10 machine with real accounts and replied ok or sent a screenshot of the error. Claude was not allowed to merge without his ok. The work covered ZCode sign-in changes, decrypting its credentials file to detect mismatched accounts, moving from print mode to ZCode's undocumented app-server protocol by recording its answers against a mock provider, four upstream merges, a Windows desktop build, a Russian translation of 1,288 strings, and two PRs to upstream reviewed by the Greptile bot.

How it went

Between 28 September and 16 October the fork shipped 8 releases, v0.3.3 to v0.3.10, from about 11 hours 16 minutes of agent work spread over 18 days: 33 commits, roughly 5,258 lines added and 1,090 removed across 61 files, and 28 new tests. Greptile found real bugs both he and Claude had missed, including chats opening in YOLO mode and approved plans that could not edit files, and scored the final PR 5/5 after fixes. Upstream maintainers have not responded to either PR. He spent $32; by Claude's own token count it would have been over $230 at API prices.

Worth knowing

Several failures only showed up on his real machine because Claude's container tested against an unofficial npm build of ZCode, so a human on the target platform stayed essential. Most of the API-price estimate was re-reading long cached context rather than output. The article does not name the harness beyond a cloud container.

Try it

With Claude· 4 parts to fill in

You are maintaining my fork of [project] at [repo URL]. Start with [the bug report or issue]. Reproduce it, find the root cause, fix it with a test, and open a PR against the fork. Then build a release candidate and stop: I will install it on [my real platform, for example Windows with real accounts] and reply ok or send the error. Do not merge or tag a release until I say ok. When upstream has new commits, merge them, rebuild generated files rather than hand-editing them, and list anything that needs my attention.

Square brackets are the parts to fill in. The prompt is ours; the story is theirs.

Where they said it

Related