Summarization
What the model receives per item, the rules it writes under, and how the reader profile shapes the digest
What the model receives
Each new item is summarised on its own, right after it is fetched. The model receives exactly two things: the item's title and up to 8,000 characters of its content (the feed text, or the extracted article when the feed only carried an excerpt). Nothing else goes along: not your other sources, not earlier summaries, and not your reader profile. Summaries are meant to be neutral records of what an item says; your preferences come in one step later, in the digest.
Summaries use the smaller, cheaper of the two configured models. See LLM providers for which models those are per provider.
The summary rules
The prompt asks for the same shape every time, in the language you configured. Its rules, in short:
Summarise the article so a reader gets the full picture without opening it: the key facts, names, figures, dates and conclusions, in four to seven sentences.
If the content is only a stub, a teaser or a bare link, summarise just what is actually there in one or two sentences instead; never invent details.
Plain, direct sentences without hype. No em dashes or en dashes.
Also list at most three short topic tags, lowercase.
For a YouTube video the summary is written from the video's description, for a podcast episode from its show notes; the prompt says so, which is why those summaries are shorter and more careful.
The model has to answer with JSON only. If the answer does not parse, it gets one retry with the error attached. If that fails too, the item is left without a summary and picked up again in the next run; one bad item never stops the others.
The reader profile
The reader profile is a short markdown document, at most about 400 words, that describes what you value: topics and angles you care about, what gets a thumbs down and why, the depth and formats you prefer, and which sources over- or underperform for you.
It is written by the model, not by you, although you can edit it at any time:
- Before every digest run, all 👍 and 👎 ratings since the last rewrite are collected, both on individual items and on whole sections.
- If there is new feedback, the current profile and that feedback go to the model, which rewrites the profile: integrating the new signals, generalising where patterns repeat, and dropping nothing that still holds.
- Your own edits are treated as authoritative and kept as the base for the next rewrite.
The profile is injected into the digest prompt, together with your last 30 item ratings and last 10 section ratings. It is not used when summarising items. So the profile changes which items are called must-reads and how the digest narrative is written; it does not change what a summary says.
In the cloud app this is the Preference profile under Settings, and Owl training lets you seed it with a prompt for your own AI assistant. See Preferences.
Models
Two model slots are involved:
- The summary model writes per-item summaries and the reader-profile rewrite. Both are simple tasks, so a small model does fine.
- The digest model writes the digest itself: structured JSON over up to 300 items, with a narrative per section. This needs a stronger model.
Self-hosted, you choose both. See LLM providers. In the cloud the models are chosen for you and their cost is part of the subscription; see AI budget and costs.