Field notes from sizing a FlexCredits pool against real query patterns. What a credit is, how it gets burned, and where the model bites buyers who priced for search and ended up paying for agents.
The first time I tried to budget a Glean FlexCredits pool, I did the thing everyone does. I opened a spreadsheet, looked up the docs, found the term "FlexCredits," found no published dollar-per-credit anywhere, and stared at it for about twenty minutes. Then I emailed a friend who actually deploys Glean. He laughed.
"You're going to estimate it," he said. "Everyone estimates it."
That's the honest start. Glean Enterprise Flex is a usage-based pricing shape sitting next to the more familiar per-seat enterprise contract. FlexCredits are the unit. Credits get burned when agents do work — deep-research runs, code-interpret calls, retrieval-heavy synthesis. The price-per-credit is not published on docs.glean.com in a way you can cite in a board deck. Procurement teams figure it out in the order form, then nobody talks about the number publicly. So what follows is the practitioner's view: how the meter runs, what a realistic pool costs, and the patterns that will eat through your budget faster than the CSM forecasted.
For the broader pricing teardown that puts FlexCredits next to the $45-50 per-seat base and the $15 Work AI add-on, see Glean pricing in 2026 and the cheaper paths to the same outcome.
What FlexCredits are (and what they aren't)
A FlexCredit is a metered unit of agent compute inside the Glean platform. You buy a pool of them. Agents draw down the pool as they run. When the pool empties, you either top up at a pre-agreed overage rate or the agent stops.
Two things FlexCredits are not.
They aren't a token billing surface. The credit cost of an agent action does not map cleanly to OpenAI or Anthropic input/output tokens. Glean abstracts over the underlying LLM call, the retrieval cost, the reranking, and any tool invocations the agent makes. One "deep research" agent action might span dozens of LLM turns and hundreds of retrieved chunks. You pay one credit cost for the whole action, not for each token underneath it.
They also aren't seat licenses with extra steps. Per-seat pricing covers the search-and-chat surface — the indexed corpus, the connectors, the basic question-answering. FlexCredits cover the agentic layer on top. A seat without a FlexCredits pool gets you search. A seat with a FlexCredits pool gets you search plus the agents that act on what was searched. Buyers who priced a Glean deal in 2024 against the seat number alone got surprised in 2026 when the agent SKUs landed underneath the same contract.
The pricing model exists because Glean's economics changed. Deep-research agents and code-interpret agents consume far more inference per query than a stock retrieval call. Glean can't recover that cost inside the seat fee without raising the seat fee to a number procurement won't sign. Usage-based pricing pushes the variable cost to the customer's variable usage. That's the whole shape.
How a credit is metered
Glean meters credits per agent action. The exact cost varies by action type, and Glean has been deliberate about not publishing a public rate card. From customer deployments I've seen plus the patterns Glean's own field engineering team will discuss in a room, the rough hierarchy looks like this.
| Action type | Approx. credit cost | What's happening underneath |
|---|---|---|
| Lightweight retrieval (single corpus, no synthesis) | ~0.5 credit | One LLM call, a vector lookup, a citation list back |
| Standard chat answer (multi-source, summarized) | ~1 credit | Retrieval across two-to-four connectors, ranking, one or two LLM turns |
| Deep research (multi-turn, citation-rich) | ~3-5 credits | Agent loop with several retrieval cycles, reranking, often a planner call |
| Code interpreter / data analysis run | ~4-6 credits | Sandboxed code execution plus the LLM reasoning around it |
| Long-document analysis (50+ page PDF) | ~3-4 credits | Chunked retrieval over the doc, hierarchical summarization, reconciliation |
| Custom workflow action (write-path, e.g. file a ticket) | ~1-2 credits per tool call | Per-tool-call audit overhead plus the action itself |
These are estimates. Your contract will land somewhere else. The point of the table is the shape: a deep-research run costs the same as five lightweight retrievals, give or take. If your power users live in deep-research, you're not buying a 1.5x premium over chat — you're buying a 3-5x premium per query.
The dollar value of a credit is the part you negotiate. Public reporting and procurement marketplace data clusters around the $0.25-0.50 per credit range for mid-market deals, with enterprise contracts at higher volumes bending lower. Your mileage will vary. Get the number in the order form, not the email thread.
A worked example: a 500-seat firm with a $50K FlexCredits pool
Here's the math I run when a customer asks me to size a pool. Names made up, structure real.
Set the scenario. Mid-market firm, 500 Glean seats. They commit to a $50,000 annual FlexCredits pool, billed up front. Of the 500 seats, 12 are analyst power users who lean on the agentic surface heavily. The other 488 use the basic chat/search layer and rarely touch FlexCredits-metered actions.
Assume a credit cost of $0.35 per credit (mid-range estimate; substitute your own once you have the order form). That gives the firm 142,857 credits in the annual pool.
Now the burn rate. The 12 analysts each run an average of 40 agent queries per week — a mix of standard chat, deep research, and code interpreter. Weight that mix at roughly: 20 standard chats (1 credit each), 15 deep-research runs (4 credits each), 5 code-interpreter runs (5 credits each). That works out to 20 + 60 + 25 = 105 credits per analyst per week. Across 12 analysts: 1,260 credits/week. Across 50 working weeks: 63,000 credits/year from the analyst cohort alone.
Then the long tail. The 488 non-analysts run maybe two FlexCredits-metered actions per week each, usually a standard chat that crosses the agent threshold. Call it 1 credit per user per week (some of those two actions are sub-credit retrievals). Math: 488 users × 1 credit/week × 50 weeks = 24,400 credits/year from the long tail.
Add it up. 63,000 (analysts) + 24,400 (long tail) = 87,400 credits per year against a 142,857-credit pool. The firm finishes the year at roughly 61% utilization, with 55,457 credits unused. Comfortable, leaning under-utilized.
But shift the assumptions a little. If the analyst cohort grows from 12 to 25, which is exactly what happens once the platform feels useful, credit consumption from that group jumps to 131,250 credits/year. Combined with the long tail, the firm now needs ~155,650 credits, which is ~$54,500 at the same $0.35 rate. They burn through the pool somewhere in month eleven and pay overage on the tail end. Overage rates are typically 1.2-1.5x the in-pool rate; call it $0.50 per credit on the overage band. The last six weeks of the year cost roughly $6,400 against a budget that expected $0.
That's the model biting. Not a malicious vendor move — just the structural reality of usage-based pricing on a usage curve that bends up faster than the original sizing assumed.
The lesson: budget for the cohort you'll have in month twelve, not month one. Then negotiate a true-up provision that lets you reset the pool mid-year at the in-pool rate rather than the overage rate. Glean will usually agree if you ask.
Where the model bites: query patterns that burn credits fast
Three patterns chew through a FlexCredits pool faster than first-time buyers expect.
Recurring "weekly digest" agents that run on a schedule. A scheduled agent that synthesizes the week's product updates across seven connectors will cost 4-6 credits per run. Run it daily across three departments, that's roughly 21 runs/week × 5 credits = 105 credits/week, or 5,250 credits/year from one workflow. Buyers schedule these without realizing the recurring cost lands inside the same pool as ad-hoc queries.
Agents iterating on themselves. Glean's deep-research agent can loop — retrieve, evaluate, retrieve again, refine the answer. Each loop adds credits. A complex research question can hit 7-10 credits if the agent doesn't converge on the first pass. There's no warning to the user; the agent just keeps spending until it lands. You see this in the audit log after the fact.
Code interpreter on large datasets. Loading a 200MB CSV into the code interpreter, asking for a multi-step analysis, getting an answer that requires three iterations of the code — that's a $2-3 query in real dollars if you back into the unit rate. Run it ten times a day across the analytics team and you've allocated a five-figure annual line item to one workflow.
The fix is observability, not throttling. Pull the FlexCredits consumption report monthly. Look at the per-user and per-workflow breakdown. If 80% of your burn is coming from two scheduled agents and three power users, that's a conversation, not a budget problem. If it's evenly distributed and growing 15% month-over-month, the underlying assumption about pool sizing was wrong.
Per-seat vs FlexCredits: which pricing shape fits your usage curve
The decision matrix is shorter than it looks.
| Your usage pattern | Per-seat fits | FlexCredits fits |
|---|---|---|
| Broad-but-shallow usage (most users run a few queries/week) | Yes — predictable monthly | Probably not — you're paying overhead per credit you don't burn |
| Concentrated power users (10-20% drive 80% of agent runs) | Awkward — power users subsidize the long tail or vice versa | Yes — pool sizes to actual consumption |
| Scheduled / programmatic agents (digests, monitors, daily reports) | Yes if usage is steady | Yes if usage is bursty or growing |
| Mixed workload with strong seasonality (quarter-end, audit cycles) | Yes — flat-rate insulation | No — bursts will blow the pool |
| Greenfield deployment, no historical telemetry | Yes — start flat, instrument, switch later | No — you don't know enough to size a pool |
A hybrid contract is the structure I see most often in 2026. Per-seat covers search and the baseline chat layer. A FlexCredits pool covers the agentic top-end. The negotiation is the size of the pool plus the overage rate, not the per-seat number. Glean will sell you either shape, but the FlexCredits-heavy structure makes more sense for buyers whose agent usage is concentrated and growing. Per-seat-heavy makes more sense for buyers whose agent usage is uniform and stable.
When you sit down to negotiate, the levers in the renewal checklist still apply. See Glean renewal checklist: five signals to renegotiate or leave before signing year two for the procurement playbook on year-two pricing — most of it transfers cleanly to the FlexCredits side of the contract.
What we still don't know
The honest paragraph. Glean's public documentation on FlexCredits at docs.glean.com describes the existence of the model but stops short of publishing a credit-cost matrix. The numbers in this article are practitioner estimates from deployments and procurement conversations, not official Glean rate cards. If a Glean field engineer hands you a different table, trust their table over mine — they have telemetry I don't.
Three things I'd still like to see published.
A canonical credit cost per agent action type. Not estimates — the actual rate Glean charges by action. Until that exists, every customer is solving a puzzle the vendor already knows the answer to.
A FlexCredits consumption SLA. When the pool runs low, what's the notification path? At 75% burn? At 90%? On the day it empties? Customers I've talked to have all three experiences. There's no committed contract behavior I've seen in writing.
A clean export of historical FlexCredits consumption at the per-user, per-workflow, per-action grain. The dashboard Glean provides is fine for spot checks. It's not fine for the budget-versus-actual review procurement needs at renewal. If you negotiate a custom export, get the schema in the order form.
Until those land in the docs, FlexCredits will keep being a thing buyers price by analogy. The analogy I'd use: it's metered like AWS API Gateway, not like an EC2 reservation. Spike usage costs more. Steady usage costs less per query. The bill arrives a month later and the line items will surprise someone the first three times.
If you're sizing a Glean deal today and the quote includes a FlexCredits pool, the questions are: what's the per-credit rate, what's the overage rate, what's the per-action credit table, and what's the true-up provision. Get those four answers in writing. Compare against the pricing teardown and the vs Microsoft Copilot comparison before you sign — Copilot's per-seat shape is the obvious alternative, and the shape mismatch tells you something about which one fits your usage curve.
The answers will be different in twelve months. The pricing surface for agentic platforms is moving faster than vendor docs.
FAQ
How is one FlexCredit priced? There's no published rate card, which is the honest first answer. From procurement conversations I've sat in on through 2026, the per-credit dollar value clusters between $0.25 and $0.50 for mid-market deals. Larger commitments bend it lower. The number ends up in the order form once the rep and the discount desk land on a volume tier — ask for it in writing and don't trust the email thread.
Can I cap my FlexCredits usage to avoid overage? Sort of, and the mechanism matters. Glean does not enforce a hard ceiling by default — the agent keeps spending against the pool until it empties, then either rolls onto your overage rate or stops, depending on what the contract says. Buyers I've talked to who wanted a hard ceiling negotiated a "stop at pool exhaustion" clause into the order form. Without it, you get the soft-cap behavior, which is closer to an alert than a brake.
What happens when my pool runs out mid-quarter? Two paths. One: you pre-negotiated an overage rate (typically 1.2x to 1.5x the in-pool rate) and the meter keeps running at that price. Two: you didn't, and now you're negotiating a top-up with a rep who knows you need the agents back online by Monday. Path two is more expensive. The fix is a true-up provision in year one that lets you reset the pool at the in-pool rate, not the overage rate.
Is FlexCredits cheaper than per-seat at my usage? Depends on the shape of your usage curve, not the size. If 10-20% of your seats drive 80% of agent runs, FlexCredits usually lands cheaper because you stop paying per-seat overhead for the long tail that barely touches the agentic surface. If your usage is broad and uniform — most users running a handful of agent queries a week — per-seat wins. The decision matrix earlier in this article is the version I run with customers; you can usually answer it on the back of one quarter of audit-log data.
Can I switch from per-seat to FlexCredits at renewal? Yes, and renewal is the right moment to ask. Glean will not generally let you reshape the pricing model mid-term, but the renewal cycle is structured around contract restatement. The data you bring matters more than the ask itself — if you can show a year of FlexCredits-equivalent burn from your audit logs, the conversation moves faster. Without that data, you're asking the rep to size a pool blind, and they'll size it high.
About this piece
I'm Ke Xue, a contributing writer on the MCP and agent-cost desk at Explore Agentic. This article is published by ASCENDING, which builds Jarvis AI — a competing agent platform priced at $1,500 and $2,500 monthly tiers on AWS and Azure Marketplace. The FlexCredits estimates here come from procurement conversations and field deployments, not from Glean's internal pricing. Treat the numbers as practitioner figures and verify against your own order form before you commit budget.