102 - Tokens and your budget

Most Plexara users are on a subscription plan. Claude Pro, Claude Max, Claude Team, Claude Enterprise, or an equivalent tier from another vendor. That means the question is almost never "how do I lower my monthly bill." The question is "how do I get the most work done inside the usage limits my plan already pays for." More questions answered, more reports written, more dashboards built, more knowledge captured, all before the session and weekly limits kick in.

Tokens are how those limits are measured. A working mental model of tokens is the difference between blowing through a week's usage on Wednesday and finishing Friday with room to spare.

Every interaction with a frontier model has two meters running in parallel. Input tokens are everything the model reads: the system prompt, the operating manual, prior turns in the conversation, any documents or catalog results that got pulled in, and the current user message. Output tokens are what the model writes back.

The two meters weigh differently against your plan. Input tokens count for comparatively little. Output tokens count for significantly more, usually between three and five times as much per token. The shape of this asymmetry is stable across providers and plans. If you only remember one thing from this section, remember that the length of the response is what decides how much of your plan each question consumes.

Abstract numbers do not help you make good decisions. Concrete numbers do. The breakdown below is the real anatomy of a first question inside a Plexara session, observed across typical operational queries against the ACME Corp demo catalog. Numbers vary by question and by connector, but the shape is stable.

Two observations worth internalizing. The platform_info load is a one-time cost per session. Follow-up questions in the same session do not repeat it, which is why long, focused sessions consume less per question than many short ones. The second observation: the trino_query result is the line most likely to blow up, because row count and column width are under your control but not the model's.

The "follow-up questions are cheaper" line on the anatomy above is true for a reason specific to Plexara: the platform tracks which tables it has already enriched for you in the current session, and shrinks the enrichment on subsequent queries that touch the same tables.

When a Trino query returns rows from a table, Plexara attaches semantic metadata to the result (description, tags, owners, column descriptions and tags, glossary terms, PII flags) so the agent can reason safely about what it is looking at. On the first query against a given table, the full enrichment is sent. On later queries in the same session, when every referenced table has already been enriched recently, Plexara switches to a compact summary or a reference, keeping only the critical fields the agent still needs (warnings, data-quality signals, sensitivity flags).

The effect compounds over a working session. A typical analysis revisits the same three or four tables from a dozen different angles. The first question pays the full enrichment cost; every question after that pays a fraction of it. This is a Plexara behavior, not a client or provider behavior, and it is scoped tightly: only Trino result enrichment is deduplicated. The platform_info load, catalog search results, and memory recall are not affected.

Subscription plans (Claude Pro, Max, Team, and the equivalents from other vendors) enforce usage through three distinct ceilings. Treating them as one number is the most common source of confusion.

The first is the context window, which is a per-request ceiling on how much the model can read at once. The second is the session limit, a rolling multi-hour window that Claude and similar clients use to pace usage across the day. The third is the weekly plan limit, the top-line cap that defines what a tier is actually selling. The three are independent. Staying inside all of them is what stretches a plan through a full work week.

Because output tokens weigh heavier than input tokens, the single most effective habit for getting more out of a plan is to ask for what you actually want. A targeted question produces a targeted answer. A vague question produces an exhaustive one, and the model has every incentive to be thorough.

Most teams pick up the habits below within their first week on Plexara. They are worth learning on purpose rather than learning the hard way, which usually means running into a session limit on a Thursday afternoon with two dashboards left to build. None of them require discipline or prompt-engineering expertise; they are just the natural shape of a discover-query-enrich session.

It is tempting to look at the token meter and reach for aggressive self-rationing: truncating context, summarizing every turn, keeping sessions artificially short. In practice, this is rarely necessary with Plexara because the recommended workflow is already the lean one.

The catalog returns small, precise context rather than whole schemas. The curated queries are pre-optimized and return the columns the agent actually needs. The export path keeps large result sets out of the conversation entirely. The agent stops when it has enough. The path that is most likely to produce a correct answer is also the path most likely to leave you with session and weekly budget to spare.

Tokens are the unit of consumption. The next lesson is about the unit of attention: what the context window actually is, what happens when a conversation fills it up, and why this is the direct reason Plexara has a persistent memory subsystem.

Six terms cover the vocabulary you will see in plan pages, limit-reached messages, and provider documentation. Learning them now means those documents read as plain English.