Context window

A context window is the maximum amount of text, measured in tokens, that a language model can take in and consider at one time when it writes a response. For meeting AI, it’s how much of the transcript the model can actually see when it writes your summary. Anything outside the window might as well not have been said: the model can’t summarize, quote or contradict a sentence it never received.

The term sounds like the reason long meetings get summarized badly. Usually it isn’t. An hour of conversation fits comfortably inside the window of any current mainstream model, so the window is rarely what limits a meeting summary. What limits it is how much of the transcript the tool chooses to send, and what it does with the rest. That choice decides what a summary can miss, and it’s worth knowing which one your tool made.

Tokens, and how big a meeting is

Models don’t count words. They count tokens, which are chunks of text: a short word is often one token, and a long or unusual word may be several. A widely used rule of thumb for English is that a token is about three-quarters of a word.

As a rough illustration rather than a measurement, here’s how that scales for speech:

Stretch of meeting	Very roughly, in words	Very roughly, in tokens
The last 30 seconds	60–80	about 100
The last 5 minutes	600–800	about 1,000
A one-hour call	8,000–10,000	10,000–15,000
A full-day workshop	50,000+	70,000+

Advertised windows vary by model and change often, but current mainstream models generally take tens of thousands of tokens at the low end and hundreds of thousands or more at the high end. Check the model’s current documentation rather than relying on any figure here. The point is the order of magnitude: a normal meeting transcript is small next to a modern window. Only multi-hour recordings, or a stack of meetings pasted together, push against the limit itself.

So if a summary of a 45-minute call leaves out the first 20 minutes, the model almost certainly could have read them. Something upstream decided it wouldn’t.

Why a tool sends less than the whole meeting

If the transcript fits, why not always send all of it? Three reasons, and they hit live tools much harder than post-meeting ones.

• Cost scales with what you send. Language-model providers generally charge by the token, in and out. A post-meeting tool reads the transcript once. A live tool that refreshes its summary every few seconds re-reads its input every time, so sending the whole meeting on every refresh multiplies the bill by the number of refreshes.
• Delay scales with what you send. More input means a slower response. After the call, a few extra seconds don’t matter. During it, a summary that arrives late is describing a conversation that has already moved on. That’s the live vs. after-the-meeting trade in its engineering form.
• Bigger isn’t automatically better. Models don’t attend to a long input evenly. A 2023 study by Nelson Liu and colleagues, “Lost in the Middle”, found that models were best at using information near the start or end of a long input and noticeably worse at using information buried in the middle. Newer models have narrowed that gap, but it’s a good reason not to assume “it fit in the window” means “it was read with equal care”.

Five ways tools handle a long meeting

What a tool does with a long transcript shapes what its summary tends to miss. Most tools use one of these, or a mix:

Strategy	How it works	What it tends to miss	Where you typically see it
Whole transcript, one pass	Send everything and summarize once	Details from the middle of a long call get thinner treatment	Post-meeting summaries of ordinary-length calls; pasting a transcript into a chatbot
Truncation (keep the recent end)	Send only the most recent stretch of transcript	Everything before the cut, completely	Live views that need to be fast and cheap
Chunk, then merge	Summarize the meeting in pieces, then summarize the summaries	Links across pieces, such as a decision made early and reversed later	Very long recordings: workshops, all-day sessions
Incremental (running) summary	Keep a summary and fold each new stretch of talk into it	Early points that get squeezed out as the summary is rewritten; errors that compound	Some live tools
Retrieval	Search the transcript and send only the parts that match a question	Whatever your question didn’t point at	”Ask your meeting” chat features

None of these is wrong. Each one fails in a recognizable way, and once you know the pattern you can often tell which one you’re looking at:

• The summary only covers the end of the meeting. That’s truncation. The beginning wasn’t summarized badly; it wasn’t sent.
• A decision that was reversed later still appears as standing, or the same point shows up twice in different words. That’s often chunking: the merge step didn’t connect the pieces.
• A summary that seems to drift from the meeting the longer the call ran. That’s often an incremental summary carrying an early misreading forward.
• An “ask” feature that says a topic never came up when you know it did. That’s retrieval missing the passage, often because the words used in the meeting weren’t the words in your question.

This is a different failure from a summary that’s wrong about what it says. A model can misstate something it did see, which is covered in extractive vs. abstractive summarization and whether AI meeting notes make things up. The context window is about what the model was given in the first place. A summary that confidently leaves out the first half of your meeting isn’t hallucinating. It just wasn’t shown that half.

What this means for a live, multi-resolution summary

A multi-resolution summary handles the window question unusually cleanly, because most of its views are short on purpose. Summarizing “the last 2 minutes” means sending the last 2 minutes, a few hundred words, which no window anywhere struggles with. That’s also why a short view should be summarized from its own slice of transcript rather than cut down from a whole-call summary: the slice is small, fresh and fast to send, and nothing from earlier in the call can crowd it out.

The pressure only lands on the widest view. A live tool that refreshes a “whole call” summary throughout a long meeting has to pick one of the strategies above for it, and each one costs something: speed, money, coverage or faithfulness.

Where Canary fits

Canary is a real-time, bot-free meeting summarizer. It captures your computer’s system audio (no bot in the call, no plugin) and shows a live, multi-resolution rolling summary — from what’s being said right now to the whole call — so you can catch up the instant your name is called.

Here’s how Canary handles the context window, plainly:

• The short views have no context-window problem. “Now” (about the last 30 seconds), the last 2 minutes and the last 5 minutes are each summarized from their own stretch of transcript, trimmed by timestamp. The “now” view refreshes every few seconds; the wider views refresh less often.
• The full-call view uses truncation. It’s built from a fixed amount of the most recent transcript. On a long meeting that’s roughly the last 10–15 minutes, so earlier discussion may not be in it. It refreshes every couple of minutes. Canary keeps that input capped so the summaries stay quick and predictable while the call is happening.
• The end-of-call decisions and action items are built the same way, from the same recent stretch. On a long call, check them against the transcript before you rely on them.
• The full transcript isn’t truncated. After the call, the review view has the complete timestamped transcript, which you can search and copy. That’s where the first half of a long meeting lives.

That trade is deliberate, and it fits what Canary is for. When your name is called, what you need is what just happened, and a recency bias is exactly right for that. For a complete record of a two-hour workshop it’s the wrong bias. Use the transcript, or a post-meeting tool that reads the whole thing once. How long it takes to get AI meeting notes covers that live vs. after-the-call trade from the timing side, and Canary vs. Otter covers it from the product side.

Practical tips for long meetings, whatever tool you use

• Read decisions back near the end. “So we’re agreed: ship Friday, Priya owns the quote.” It’s good facilitation anyway, and it puts the decision in the part of the meeting every strategy above is most likely to catch.
• Check early-meeting items against the transcript. If something important was settled in the first ten minutes of a long call, confirm it’s in the summary before you act on the summary.
• Split long sessions. A workshop run as separate sessions, each with its own notes, avoids the window question entirely.
• Ask narrow questions of a long transcript. If you paste a transcript into a chatbot (see Canary vs. ChatGPT), “what did we decide about pricing, and who raised the objection?” gets better answers than “summarize this”, because it tells the model where to look.
• Know which view you’re reading. A “full call” label tells you what a summary is meant to cover, not what the model was actually shown. How accurate AI meeting notes are depends on both.