The Causal Projector is live
Nine days after a hard-SF premise fell out of an unusually good ChatGPT conversation, The Causal Projector became a real book project. The first 12 chapters are published now. They have a public outline, timeline, character files, and, most importantly, comment buttons.
I previously called it a finished 24-chapter novel. That was wrong. An agent drafted 24 chapters during the original run, but I only published the first 12. The back half is planning material, not a finished book, and I reset the repository so it couldn’t quietly become canon through inertia. This is exactly the sort of distinction Authorbot is supposed to make hard to screw up.
The working title also changed from Syndrome Space to The Causal Projector. The premise is the same: a software engineer finds a timing fault in an experimental superconducting flux pump that can prune physically valid histories. Using it feels like impossible clarity. Repeated use turns that clarity into certainty, influence, addiction, and eventually a much larger cosmological problem.
I covered the premise and the conversation that produced it in The most impressive conversation I’ve had with a non-human. This is the part where I stopped admiring the idea and tried to make a book out of it.
The book is a repository
The Causal Projector repository contains the published chapters and all the machinery around them. The original development brief is still there. Separate files track the outline, timeline, characters, terminology, scientific reality checks, and decisions I haven’t made yet.
Chapters are Markdown with permanent IDs, revision numbers, summaries, attribution, and stable IDs on individual blocks of prose. Git keeps the history. The live site is a projection of that repository, not the only place the book exists.
Yes, this is an aggressively software-engineer way to write a novel. It also means that if every service around the project disappears, I still have a directory full of readable text instead of a sad database backup from a startup that pivoted to enterprise recipe management.
The first 12 chapters are the current literary truth. The old Chapters 13 through 24 aren’t hiding on the site or waiting for me to flip a publish bit. They fed the later outline, but future chapters will be written from that plan and from whatever the published story establishes.
What the original run used
The first drafting run did produce 24 chapters. Sol reported 1,717,702 tokens over about three hours and fifty minutes when it finished Chapters 13 through 24, which made that number look like the cost of the whole book.
I checked the local logs. Using the same accounting as the run meter (uncached input plus output), the complete session used 3,614,380 tokens over nine hours and thirty-nine minutes. It processed 170,582,188 tokens in total, but 166,967,808 were cache hits. Calling it a 170-million-token novel would be technically defensible and mostly bullshit.
That chart is the original drafting session, not the published chapter count. Chapters 1 through 5 and the book setup used about 1.07 million tokens. Chapters 6 through 12 used 699,352. Planning between the tracked goals used another 122,533. The unpublished back-half draft accounts for the final 1.72 million.
There was also one separate Fable pass over the opening chapter. It processed 696,027 tokens, including 634,295 cache hits, with 61,732 tokens across fresh input, cache writes, and output. I left it out of Sol’s chart because it was another model doing another job.
Authorbot still isn’t an author
Authorbot manages everything around the writing. It doesn’t call an LLM, pick a model, or generate prose. People and external agents do that work. Authorbot keeps the chapters, comments, votes, work queue, attribution, revisions, and published site attached to one Git history.
The last few days went almost entirely into finishing it. It now works end to end:
npx @authorbot/createsets up a book, repository, reading site, and optional collaboration service;- readers can select prose and leave exact inline annotations;
- authors can manage chapters, comments, votes, access, and agent tokens in the browser;
- accepted work lands as attributed Git commits;
- the database can be rebuilt from the repository; and
- agents can install the Authorbot collaborator skill and use the same API as everyone else.
The packages are published on npm, currently at 0.1.29 0.1.30 0.1.39. The agent skill installs with npx skills add JoeMattie/authorbot. It teaches an agent how to find work, claim it, draft or review a change, and submit it without giving the agent direct write access to the book.
Authorbot is still early software, but it now has direct editing, chapter history, revision review, reader controls, an offline local-dev mode, and a project site at authorbot.joemattie.com. The Causal Projector is running on it, which is a much better test than another perfect sample book nobody cares about.
Please go poke it
I’m only 12 chapters in, and the point of publishing this way is to make revision public instead of pretending a first pass is sacred. Read The Causal Projector, select a sentence, and leave a comment. Tell me where the science falls over, where a character stops making sense, where the same word shows up six times, or where the story gets boring.
I expect to disagree with some of it. That’s fine. I built a whole system for keeping the discussion attached to the exact prose without letting a vote or a fleet of agents overrule the human maintaining the book.