Forem: Terry Zhang

The Story That Almost Wasn't — How LlamaGen Changed Everything December 4, 2024

Terry Zhang — Fri, 03 Apr 2026 04:28:47 +0000

There is a moment every artist knows.

You sit down. The canvas is white. The cursor blinks. And somewhere between the story burning in your head and the page in front of you, something seizes up. Not a lack of ideas — you have too many. Not a lack of will. Something more primal: the terror that what you make will be smaller than what you imagine.

I've spoken to hundreds of comic artists, animators, and game creators over the past few years. The blank page comes up every time. Not as a metaphor. As a real, recurring experience that has stopped real stories from ever being told.

That conversation is why I built LlamaGen.Ai.

What the Blank Page Actually Costs
Jenny is a freelance comic artist based in Berlin. Eight years of professional experience in traditional manga-style storytelling. She described her studio before she found us: a small room, a drawing tablet, and the particular kind of paralysis that sets in when you have a story but can't yet see it.

"I would spend days sketching rough layouts," she told me. "Second-guessing every panel composition before a single line felt committed."

Her story is not unusual. It is, in fact, the rule.

The economics of visual storytelling have always been brutal in a way that writing and music are not. A sentence costs nothing to revise. A comic panel — with its composition, lighting, character expression, and sequential logic — can take hours. An anime episode takes hundreds of artists and months of grinding work. The gap between idea and execution is so wide, and so expensive, that most of the world's visual stories simply don't get made.

Not because they aren't good enough. Because the people who carry them run out of time before they ever begin.

A Simple Idea, Extraordinarily Hard to Build
When Jenny uploaded her first story to LlamaGen.Ai — a girl discovering a magical garden — eight rendered comic panels appeared within moments. Not placeholder sketches. Panels that captured the wonder she had imagined but struggled to get on paper.

"It wasn't just about the technology," she said. "It was about transforming that intimidating blank canvas into a springboard."

That is the sentence I want to put on everything we build.

The idea behind LlamaGen.Ai is almost embarrassingly simple: a creator should be able to describe what they see in their head, and a machine should render it — panels, characters, storyboards, the full visual architecture of a story — in seconds instead of months.

Simple to say. Genuinely hard to build well.

We needed a system that understood sequential art not just as a collection of images, but as a language — with grammar, pacing, the weight of a silent panel, the logic of a face changing across six frames of emotion. We needed character consistency: the same person, recognizable at panel 1 and panel 300, through different lighting and angles and expression. We needed it to understand that a comic page is not a gallery. It is a time machine.

The Skeptic's Journey
Jenny came to us skeptical. Most artists do. The question is always some version of the same fear: will this make my work less mine?

What she found — what I hear from creators across twelve countries now — is the opposite. The AI doesn't replace the artist's vision. It amplifies it. The generated panels become a dialogue: the machine offers a perspective, the artist responds, the story emerges from the conversation.

"Sometimes an unexpected angle would spark an entirely new direction," she said. "Perspectives I hadn't considered. I started exploring artistic territories I might have otherwise overlooked."

That is not automation. That is collaboration. And it changes the creative process at its root — not by removing the artist, but by eliminating the specific suffering that happened before the artist could begin.

What We're Actually Building
LlamaGen.Ai is, on the surface, an AI platform for comics, anime, and game creation. But the mission underneath is bigger than the product.

We want to build a world where every story that deserves to exist gets made. Where the creator in Osaka with the story that should become a series isn't stopped by the cost of a studio. Where the blank page is no longer a barrier, but an invitation.

The greatest IP in history — the characters and worlds that have become cultural infrastructure — started as someone's drawing on paper. We believe AI unlocks the next generation of that. Not by replacing artists, but by giving every artist an impossibly fast, impossibly patient creative partner.

Jenny put it better than I could: "Starting with AI-generated panels doesn't limit creativity. It opens up possibilities I never knew existed."

That's the product. That's the company. That's why I show up every day.

The blank page was never the enemy. We just finally built something to prove it.

— Terry

Why I Started AFFiNE - August 3, 2022

Terry Zhang — Fri, 03 Apr 2026 04:28:12 +0000

Every great product begins with a question you can't stop asking. Mine was: What if your data truly belonged to you?

The Spark
I'd spent the better part of two years inside a large engineering team, working on online documentation infrastructure. The codebase was aging. The tooling was borrowed from architectures designed for someone else's constraints. Every time a user lost work to a sync failure, or couldn't access their notes offline, I felt the gap between what we had and what was possible.

I started building experiments in the margins of my actual job — prototypes of a different kind of editor, one that kept your data on your device first and treated the server as optional rather than essential. A local-first architecture, before I'd even heard that phrase used widely.

Those experiments consumed my nights. And the more I built, the more convinced I became that the right answer couldn't live inside corporate walls.

The Leap
So I left. No roadmap approved by a committee, no guaranteed runway — just a conviction that the problem was real, the timing was right, and that the only honest way to build something people could truly trust was to build it in the open.

That decision was the founding moment of AFFiNE.

The Vision
AFFiNE is a next-generation knowledge base — a place where planning, organizing, and creating are one continuous flow, not three separate apps that barely talk to each other.

Privacy-first. Open-source from day one. Built to run on your machine, for real, not as a marketing footnote. The editor and the data layer are both open for anyone to inspect, fork, or contribute to.

We refused the trade-off that most tools accept quietly: that you must surrender ownership to get great features. That offline means falling behind. That collaboration requires handing your documents to someone else's cloud.

A Different Philosophy
With AFFiNE, your data stays on your device first. Collaboration happens when you choose to enable it — peer-to-peer, not routed through a platform that has interests of its own.

We're building the kind of tool I wish had existed when I first started asking these questions. Not because it's technically elegant, though I believe it is, but because it reflects a principle worth fighting for: the tools we use to think should work for us, not the other way around.

Looking Forward
I started AFFiNE because I believe the software we use to create and collaborate should empower us, not extract from us. We're early. There is a long road ahead.

But the question that started all of this hasn't changed.

What if your data truly belonged to you?

We're building the answer.

— Terry

What I Learned from Watching Google Docs Work — and Why It Changed Everything December 15, 2020

Terry Zhang — Fri, 03 Apr 2026 04:27:51 +0000

I typed a single sentence into Google Docs.

"Embrace every kind of life" — a phrase from my work in writing, nothing special. Then I did what any curious engineer does at 2 AM with too much coffee: I opened the network tab and watched what happened.

Thirty-four discrete edit operations flew to the server before the sentence even finished rendering.

Thirty-four.

I sat back and stared at that number for a long time. That one moment — watching a handful of characters explode into dozens of atomic network requests — cracked open something I hadn't expected. What I thought was a product question turned into a philosophical one.

The Protocol Is the Product
Most engineers, when they think about collaborative editing, reach for the algorithm first. OT, CRDTs, conflict resolution — the academic machinery. I made the same mistake.

The real insight came earlier, at the protocol layer.

When I traced those requests, what I found wasn't a document being synchronized. It was a stream of commands — each one atomic, composable, and reversible. The operations mapped cleanly into four primitives:

create — bring a new entity into existence
update — mutate an existing property
delete — remove
tether — bind an entity to a position in the document
That last one surprised me most. Inserting an image isn't a single operation in Google Docs. It's a choreography: first a special placeholder character, then an addEntity call, then a tether to bind the entity to that position. Verbose, yes. But exquisitely trackable, replayable, and mergeable across any number of concurrent editors.

The protocol wasn't an implementation detail. It was the product.

A Document Is Not a String
Once I understood the protocol, I started working backwards to the data model — and the comfortable intuition that "a document is a string" collapsed almost immediately.

The top-level structure of a Google Doc contains: body, documentStyle, lists, namedStyles, revisionId, and more. The body is a sequence of StructuralElement objects. Paragraphs contain ParagraphElement runs. And the index system doesn't count characters — it counts UTF-16 code units, which means a single emoji (a surrogate pair) consumes two index positions.

These are the kinds of details that sound pedantic until the day you try to build comments, undo/redo, cross-device sync, or tables. Then they become life-or-death decisions. A string-based model will eventually crack. A structured object model keeps evolving.

The Three-Version Problem
After the protocol and the data model, I hit what I now think of as the true heart of collaborative engineering: version management.

The problem is simple to state. Every client is constantly producing diffs and pushing them to the server, which broadcasts them to everyone else. But networks are unreliable. So at any given moment, every screen in a collaboration session is showing a slightly different document.

To prevent this from spiraling into chaos, every command must be stamped with the revision it was based on. And to handle network failures, reconnections, out-of-order arrivals, and concurrent submissions, each client must simultaneously maintain three versions of the document:

Server version — the last confirmed state from the server
Sent version — changes dispatched but not yet acknowledged
Editor version — local edits not yet sent
When a conflict arrives — when someone else's changes land before yours are acknowledged — the system performs something that feels like git rebase. It replays the incoming changes before your pending queue, applies inverse OT corrections to the unconfirmed operations, and reconciles everything without either party losing their work.

This is not academic rigor for its own sake. It's the engineering contract that makes collaboration feel effortless, even when the underlying reality is anything but.

Why This Led Me to Open Source
When I finished filling my Notion with all of this — every protocol detail, every data structure, every version-management edge case — I felt two things at once.

I was in awe of the engineering. It is genuinely beautiful. Precise, resilient, elegant under pressure.

And I was troubled.

Because this kind of capability is extraordinarily expensive to build and maintain. Which means it will naturally concentrate in the hands of a few large platforms. And when your documents live on someone else's server, you don't truly own them — you're renting access to your own thoughts.

That realization sharpened something I'd been circling for months into a clear commitment:

Collaboration should be more accessible, not less. And users should truly own their data.

When those two things become your north star, open source stops being a technical preference and starts being the only honest path. Open source means the capability can be copied and carried forward. Trust can be verified rather than promised. Self-hosting, migration, backup — these become facts, not features on a roadmap.

That winter, tracing a single network request through Google Docs, I didn't know where any of this was pointing. But every line I wrote in those notes was quietly sharpening one conviction:

Build it open. Give users their data back. Make the powerful tools available to everyone.

— Terry

LlamaGen.ai Comic API – Seeking Feedback from the Community

Terry Zhang — Fri, 03 Apr 2026 04:15:47 +0000

Hi everyone,

I'm the founder and CTO of the open-source project AFFiNE (https://github.com/toeverything/AFFiNE), which currently has 66.9K stars on GitHub.

Recently, I built a new project called LlamaGen.ai — an AI platform for generating comics and manga. As part of it, we’ve created a Comic API specifically for developers.

I also published the official JavaScript/TypeScript SDK as the npm package comic (npm i comic).

The API supports generating multi-panel comics (1–20 panels), character consistency (via reference images or character descriptions), various styles (including 500+ presets and custom styles), and different aspect ratios. It accepts text prompts, and higher plans support image-to-comic, video-to-comic, and document-to-comic workflows.

Quick SDK Example

npm i comic

import { LlamaGenClient } from 'comic';

const client = new LlamaGenClient({ apiKey: 'YOUR_API_KEY' });

const result = await client.comics.generate({
  prompt: "A brave fox warrior fighting a giant robot in a neon cyberpunk city, dramatic manga style, 4 panels",
  panels: 4,
  style: "manga",
  character_consistency: true
});

Right now, I’m actively looking for honest feedback and real experiments from the developer community. I want to know how people might actually use it, what works well, what’s missing, and how it can be improved.

For more details, API reference, full parameters, and examples, please check: https://llamagen.ai/comic-api

If you’re interested in trying the API or SDK, feel free to leave a comment below or send me a message. I’ll happily send you some experience credits to test it out.

I’d really appreciate any thoughts, use case ideas, prompt tips, or integration experiences you might have.

Thanks in advance!

Tags: AI, Comics, API, ImageGeneration, Manga, OpenSource, Feedback, SDK, JavaScript

Useful Links:

AFFiNE: https://github.com/toeverything/AFFiNE
LlamaGen.ai Comic API: https://llamagen.ai/comic-api
Main Platform: https://llamagen.ai
npm package: https://www.npmjs.com/package/comic