Cursor Projects' orchestrator rewrote its plan file 111 times and read it once

The 111 writes to notes.md came over roughly 14 hours of sessions, about eight an hour, against one explicit read ^[3][5][3]. An orchestrator that works this way treats the plan as output. Its working memory is whatever is still in its thread.

Cursor's design depends on that thread. One orchestrator thread runs for the whole project and does no work itself. It starts agents on cloud machines and collects what comes back ^[1]. A shared context folder on a file system fills up in the background, and every agent can read it ^[2]. The author describes the underlying problem as an agent session that starts empty, gets filled with the plan, the state and the relevant files, and starts over when the window is full ^[14]. A plan that is written but not reread does not carry into the next window. "For professional projects, it still loses decisions," the author wrote ^[18].

Delegation is the part that worked, and it is good engineering. Roughly 1.6 tasks per agent and four of five PRs merged is a clean hand-off ^[7][1]. Inputs were messy. The podcast has two RSS feeds with different schemas, the Patreon one alone 13 MB, and transcripts come as JSON or VTT when they exist and from Whisper when they do not ^[17]. On the author's ioBroker server the adapter now runs unattended, and its latest run found eleven open questions, each with a timestamp ^[8]. I also trust the review method more than most. After the run, the author exported the orchestrator chat, agent threads and context folder, then had an agent check the author's impressions against that record. Some held up and some did not ^[16].

The 111-to-one figure comes with qualifiers. Model selection stayed on Auto on the $20 Pro plan, and the usage page attributed all of it to Cursor Models, meaning Cursor Grok and Composer, at 16% of that quota ^[9]. "So some of what follows may come from the model rather than the tool," the author wrote ^[10]. The run used Cursor out of the box, with no skills, rules or custom prompts ^[6]. The author calls a single beta run one data point ^[20]. A team whose rules file forces a read of the plan at the start of every turn is running a different experiment. This run also had a rule of its own: the author read no code, planned the architecture with the orchestrator, had it explain what it built, and tested the result as a black box ^[15].

The author's proposed fixes are a decision log the orchestrator reads every turn, a context folder under version control, and one owner for each PR's review comments however many agents subscribe to it ^[11]. I'd start with version control. It is cheap, and a decision deleted from notes.md shows up as a removed line in a diff that someone can review. A per-turn log costs more, since it spends context on every turn and has to stay short to be worth reading. Write-heavy, read-once is a fine profile for an audit log and a poor one for a plan. In the author's view, skills or rules can probably cover some of this, and the rest will likely improve as the beta matures ^[12]. Casefile, a skill set the author had already built, exists for the same job of loading plan and state into a fresh session ^[13].