This is for non-urgent questions that Query is unable to resolve or a Support Ticket is needed

Get help from Glean Support Team

I wanted to share some observations and feedback around Glean Canvas performance that I think could be helpful as the feature matures. We've been using Canvas fairly heavily for iterative drafting and refinement of longer documents, and it's genuinely a great fit for that workflow — the inline editing, version history, and export capabilities are excellent.

That said, we've noticed a few things during heavier sessions that I wanted to flag constructively.

Progressive slowness during longer sessions:

 Canvas interactions remain snappy in the first few turns of a conversation, but once the session involves several tool calls (searches, activity lookups, email retrieval, etc.) the response times increase noticeably. By turn 8–10 in a research-heavy session, the lag becomes quite pronounced compared to fresh conversations.

 On longer runs — particularly bigger edits or multi-section rewrites — the assistant occasionally reports that the operation is complete, but the Canvas content doesn't update, or only partially updates. It looks like the model output may be getting truncated, and the UI doesn't clearly surface that the write-back didn't fully complete.

 because Canvas is genuinely the right tool for our use case. The current experience just makes it hard to fully trust for longer working sessions, and we sometimes end up copying content out to other tools as a safety net, which reduces some of the value.

What I Tried to Understand — The Model's Own Perspective

To better understand what's happening, I asked the assistant to describe its own mechanics during a Canvas session. Here's what it reported (lightly edited for clarity):

No separate tool is invoked by the model to create a Canvas — it generates structured XML as part of its text response. The Glean platform then parses and renders this in the Canvas panel. So from the model's perspective, a Canvas is just structured text output.

 tool, which takes three inputs: the artifact name, the exact text to find, and the replacement text. It performs a literal find-and-replace — one replacement per call. If multiple edits are needed, that's multiple sequential tool calls, each requiring a full LLM inference cycle to determine what to change.

From the model's perspective, there is no distinct "re-read" of the Canvas — the canvas content is part of the conversation history that gets re-processed each turn. The Glean platform may manage this differently internally, but from the model's side, the entire conversation — every message, every tool call input and output, every artifact — appears to be re-sent on every single turn. This is consistent with how transformer-based LLMs generally operate in chat.

What a Heavy Session Looks Like (Example)

In one session, the model reported the following approximate context accumulation:

Note: The sizes above are the model's own estimates based on the volume it processed — not measured values. Actual token counts are not visible to the user or the model.

By turn 9, the model estimated it was processing well over 100,000 words of cumulative context. The progressive slowness directly correlated with this accumulation.

These are offered as ideas for discussion — I understand the platform is evolving quickly and some of these may already be on the roadmap.

Tool results appear to be stored with minimal compression in the conversation context. In one case, a search returned an estimated tens of thousands of words, of which the model used perhaps a few hundred in its response. The unused portion remains in context for all subsequent turns.

 After the LLM has processed a tool result, summarize or truncate the stored version. Keep the relevant excerpts, discard the raw payload. This is sometimes called context compaction or memory summarization.

The Canvas artifact and tool results appear to share the same context space. As tool results accumulate, the Canvas content itself may be at risk of silent truncation — meaning the document the user cares about most could be the thing that gets partially evicted.

 Treat the active Canvas as a pinned context block that's always preserved at full fidelity. If context needs to be trimmed, prioritize evicting older tool results before touching the artifact.

Currently there's no indication of how much context capacity has been consumed, whether earlier content has been truncated, or why a response might be slower than usual. The only signal is when things feel laggy or output quality degrades.

 A simple visual indicator for context utilization — even a traffic light (🟢 fresh / 🟡 getting heavy / 🔴 near capacity) — would help users make informed decisions about when to start a new conversation.

Tools appear to return their full result set regardless of how much context is already consumed. A search early in a conversation and a search at turn 9 return the same volume, even though the available context budget is very different.

 When context utilization is already high, return shorter or summarized tool results automatically. Or provide a mechanism for the model to request "summary mode" from tools.

E. Canvas Continuity Across Conversations

The main workaround for context bloat is to start a new conversation — but the Canvas doesn't carry over. This creates a tension: you want a fresh context for performance, but you need the existing Canvas for continuity.

 A "Continue this Canvas in a new conversation" option that brings only the artifact into a fresh context, leaving behind all the accumulated tool history.

Canvas is a genuinely useful feature and we'd love to use it more heavily. The core challenge isn't the Canvas itself — it's that the cumulative context growth in research-heavy sessions creates progressive performance degradation. The suggestions above are focused on managing that context lifecycle more transparently and efficiently.

Side observation — Canvas feels noticeably more responsive on weekends compared to weekday business hours. Could be coincidence, but it's been consistent enough to notice. If the LLM inference layer is shared infrastructure, this might point to load-related latency rather than a pure context-size issue.

Canvas performance and reliability when working with large model drafts

Home

Forum

Events

Content

Courses

Collections

People

Contributors

Albums

Groups

Chat

Channels

Tools

Help

Welcome to the Gleaniverse. Empowering work with AI. Connected by knowledge. Growing together. Search Where would you like to start? Join the discussions.

Glean Community

Gleaniverse Community

Copyright

Terms of Service

Privacy Policy

Code of Conduct

Your Privacy Choices

It looks like there is no account associated with the email you provided. The event is for members only. Please complete the application to join our community first.

Thank you for your interest in joining us

Thanks for your interest in joining the event. However, your account is still pending. Once it's approved, you'll be able to register for the event. Please contact us via community@glean.com if you need support.

Pending Approval

Login to the Glean Community to connect with others, attend community events, and more!

Login or Sign Up for even more

To unlock all parts of the community and get the best experience, complete your profile.

Hey, complete your profile

It looks like there is no account associated with the email you provided. Please complete the application to join our community.

Thank you for your interest in joining Glean Community.

Thanks for your interest in joining Glean Community. We will review your request shortly and email you once it's approved. Meanwhile, please feel free to contact us via community@glean.com for any questions.