When I aligned myWiki storage to two source/wiki file layers, the second mechanism was still in my head. Collect, put on a shelf (classify), leave organized wiki sentences (summarize), query when needed. Move that loop into app features and done. No need to transplant skill files or a one-shot ops bundle from the terminal. Mechanism was enough, I thought.
Billing was the difference. second sits closer to my subscription and local CLI. The product bills every call on API keys. Every call hits a ledger. I only felt that in the body later.
Reading everything and synthesizing was not an option
Once the organize pipeline existed, it still did not feel like a wiki. One source in, intake decides create a new doc or attach to an existing one (reflect), then writes a body right away. Ambiguous cases leaned create. Doc count tracked sources almost 1:1.
My lines are still there. 「소화가 너무 1:1인데 통합되어야할거같은데」. Then 「소화할때 바로 편집하는게 아니고 종합해서 편집해야할거같은데」. Look at the classify map, align several sources at once, rewrite the body as one synthesis. The feel I sometimes got in second. Read widely, clean once.
On a product that runs on API keys, that was cost explosion. Stuff candidate bodies and map meta whole and input alone blows up. Synthesis output is long too. On real ledgers, most cost was organize, not chat. Flagship models plus big inputs stacked. I will not paste unit-price tables here. The sense was clear. The product cannot imitate second’s full-analysis summarize every turn.
So I changed the summarize bar. Compress the source toward a short summary first, then turn that into wiki sentences. Drop whole-corpus synthesis as the default path. At intake, inject only map meta: title, summary, tags, path. Not full bodies. Prefer attach. Create only for a truly new topic. Even when attaching to an existing doc, do not let the model rewrite the whole body. Mechanically stitch sections. Aim for about one intake-decision’s worth of predictability.
I thinned the classify map too. second stacks pin, chrono, structured axes. In the app, after latency and cost, I kept structured plus a chat-facing wiki map. Chrono caches and source-toc-like layers went. Pin stayed as a signal that does not create documents. Classify ends closer to the wiki-side map. A thinner map makes query simpler, and also makes document files fragment more easily.
When files multiply, merge arrives
Even when 1:1 felt less, docs still piled up. Upload batches, session deltas, spaces where create suppression fails. Cards multiply. Admin merge became central: a tool to bind already-split docs later.
Early on I tried merges where the model rewrote bodies. Calls grew per cluster, and redrawing the map on every write made it slow. Running a merge call inside every summarize doubled calls on a handful of files. Time bomb and token bomb. I drew a line: documentation speed first. Attach mechanically. Polish later.
Merge planning was heavy for a while too. I typed 「sasame 병합」 in the instruction and once got a plan to merge every document. Too much summary/tag/body-adjacent meta and the model tilted to “bind everything.” So next: 「그리고 계획 너무 느려 제목만 보고 계획 잡게 수정해줘」. Plan input shrank to id and title. If there is an instruction, narrow candidates by that keyword first, then only assign cluster numbers inside that set.
A trap remained. In a space with hundreds of docs, one plan call grew to roughly 47k input tokens, output max 1200 cut the answer, and I got clusters: []. Empty plan. We later tightened candidates, split plans, and raised output caps, but the lesson is simple. Even planning “all at once” truncates.
Final shape locked like this. Ask the model only for titles, short summaries, and which ids go in which cluster. After approval, stitch bodies in order. Headings under a representative doc. No body-rewrite call on that path. Modules split into plan, apply, pure helpers. If plan is slow, look at plan. Apply stays deterministic.
For a while I even felt classify-map-only was cleaner. 「오그래도 주제 합치는게 오히려 인덱스만 보는게 더 깔끔하네」. In practice one title-list pass to the model stayed, but not feeding bodies stayed. Merge quality got refined more by shelf and keyword constraints. That is a later later story.
Frequency is a lever too
I did not only cut unit price. Not running is zero. Earlier, a few idle minutes after the last chat reply auto-enqueued wiki-ization. Felt convenient. Keep talking and jobs still stack. On 07-18 we removed that product path. Now the default path is manual capture, re-running sources, and admin organize. If auto comes back, stretching the interval is weaker than skipping the model when new text is tiny. Frequency sits on the same line as unit price.
I also wired official API rates into the ledger. 「토큰비용 api검색해서 계산해서 넣어줘 일단 공식 api 비용으로」. A request to align number sources. No table in this post. What mattered: once measurement existed, you could see where organize grew.
Giving up became design
Three lines left. I did not put second-style “read everything and synthesize” summarize on the default path of an API-key product. What remained: compress sources, tidy wiki sentences, a thin structure map. Files multiply, merge arrives; merge also drops body rewrite and only takes clusters from title·summary, then stitches. Idle auto-summarize off; only when a person turns it on.
The wiki is thinner. Cost is more predictable. Not a knowledge base melted into perfect single pages. More like a shelf that stacks fast and binds later. That binding, splitting again, and undoing bad merges is where management starts. Next comes the day I asked to fix a title and the body disappeared.