If you've asked a coding assistant to fix one small thing and then wondered where all your tokens went, you're in good company. A sentence or two in the chat can lead to a surprisingly large usage total, even when the answer looks fairly short. It's worth looking at what happened before assuming you need a more expensive plan.
Recent questions in the Cursor community and Claude community ask about exactly this: long conversations, cached tokens, and whether a fresh chat will help. That gets confusing quickly when you're trying to work out what a client project will cost.
If you're using AI or agentic coding tools for FileMaker development, it helps to understand what those usage numbers are counting before changing plans. We'll look at context, caching, and a few practical ways to keep FileMaker scripts, exports, and sample data from adding unnecessary work. The same ideas apply to connected web applications.
Your prompt is only part of the request
Tokens are the units a model uses to process content. A token isn't necessarily a word; a word, a piece of code, or a number can be split into smaller pieces. The exact count depends on the model and the content.
In a coding tool, the request can include project instructions, earlier messages, file contents, tool definitions, and results from searches or commands. The sentence you typed is added to that material. A short question can therefore lead to a much larger request.
Cursor describes this repeated setup in its explanation of token efficiency. It also points out that the conversation grows as work continues. That gives you a better starting point for investigating usage than counting the words in your last message.
A context window and a usage total measure different things
The context window is the amount of material a model can work with in a single request, subject to that model's rules about input, output, and reasoning. A session usage total adds up work across requests. Those numbers do not have to match. Anthropic's context-window documentation explains the request-level limit.
For a simple example, imagine ten requests that each include 20,000 input tokens. That adds up to 200,000 input tokens across the session, even if no individual request uses more than 20,000. This is an illustration of counting, not an estimate of your bill. Caching, output, and other usage categories still need to be considered.
Before interpreting a dashboard, check whether it shows current context, cumulative usage, an allowance percentage, or estimated cost. A large cumulative total doesn't tell you how close the current request is to the model's context limit. And a small context indicator doesn't tell you how much you've used over an afternoon.
Cached tokens can still appear in your usage
Prompt caching lets a provider reuse processing for eligible repeated input. That can make repeated material cheaper to process, but it doesn't mean the material has disappeared from the request. A cache-read count is not automatically a sign that something has gone wrong.
Anthropic distinguishes ordinary input, cache writes, and cache reads, with different pricing rules. Its prompt-caching documentation covers those categories. Check the rates for the model you're using rather than applying one rate to the whole token total.
OpenAI's caching guide likewise describes separate usage fields and model-specific caching behavior. If you're building your own API application, keep the stable part of the request consistent and inspect the returned cache statistics. If you're using a coding application, much of that request assembly is handled for you.
I wouldn't keep an unrelated conversation alive just to preserve a cache. The old material still has to be useful for the next task. On the other hand, restarting halfway through a focused job may require the assistant to read the same files again. Look at the work you're continuing before deciding to reset.
AI token management for FileMaker development
FileMaker developers have an extra reason to be precise about the word “token.” The FileMaker Data API returns a session token when you authenticate. That is a credential used to access the database. The AI tokens we're discussing here measure content processed by a model. A valid Data API token doesn't tell you anything about the amount of AI usage a coding session will consume.
For agentic coding with FileMaker, I'd begin with a fairly specific request: name the script or calculation you're reviewing, explain where it runs, and show the result you expect. If you want to investigate an invoice total, the relevant script, layout, table occurrence, and a made-up invoice example give the assistant somewhere useful to start. It may need more information, but you can add that as the investigation develops.
Be careful about sending the whole solution
A solution export can be useful for a broad review. For a small script fix, check whether your tool can inspect the relevant objects separately before attaching the entire export. The tool may already load information selectively. Ask what it retrieved, and use its context or usage report where one is available. You can't work out the AI token cost from the size of the FileMaker file alone.
The same goes for data returned through a connector. A few sample records with the fields involved in the problem may be enough to reproduce it. There's usually no reason to fetch thousands of customer records to explain why one invoice calculation is wrong. Check that the smaller sample still includes the condition causing the error, and leave out real customer information wherever possible.
Keep the FileMaker details that affect the answer
Don't trim away the script parameter, layout context, or relationship involved just to save tokens. Without those details, you may spend the next few turns correcting an answer that made sense in a different context. A short request like this is a better place to start:
EXAMPLE FILEMAKER REQUEST
Review the invoice-total script in the development copy. I'll provide the script, the layout and table occurrence it runs from, and a sample invoice with the expected total. Start with those. If you need another script or relationship, tell me which one and why.
Check whether the calculation handles an invoice with no line items and a discounted line item. Leave the schema, privilege sets, and sending workflow alone. Explain what you could verify and what still needs testing in FileMaker.
When you finish, save the relevant object names, decisions, and test results in your handoff. The next session can then begin with the current state of the work. You won't need to retell every failed attempt from the previous conversation.
Give it a place to begin looking
“The invoice total is wrong” doesn't tell the assistant where to start. It may need to search the project, inspect several files, and ask questions before it can reproduce the problem.
If you know the affected layout, script, or endpoint, include it. Describe the expected total, the total you got, and a sample record that reproduces the problem. If you're unsure where the bug lives, say which part you've already checked. This helps narrow the investigation without telling the assistant to ignore possible dependencies.
For FileMaker, I'd begin with the relevant script or calculation, the layout and table occurrence it runs from, and a short description of the business rule. If a web application calls it, include that route as well. The assistant may need more information, but it has a sensible starting point.
Don't remove error details or context simply to make the request shorter. An assistant that has to guess, fail, and ask again can use more tokens than one given a slightly longer, clearer description at the start.
Be selective with exports, logs, and tool results
A whole solution export can contain far more than a particular task needs. The same goes for a large JSON response or several days of logs. Start with the part that explains the failure, and keep the original available for further inspection.
Cursor's dynamic context discovery article describes using files and selective reads rather than putting every long result directly into the working context. The approach is useful to keep in mind when deciding what to attach yourself.
Instead of pasting an entire log, provide the relevant error, its timestamp, and the steps that caused it. For an API response, include the error code and the fields needed to understand it. Remove credentials and unnecessary customer information. If you supply an excerpt, label it as an excerpt so the assistant doesn't assume it has seen the whole result.
For a FileMaker export, ask whether the tool can inspect individual scripts or objects. If it can only read a larger export, you may have to accept that initial cost. Don't claim a tool is sending your whole file on every request unless its documentation or usage evidence shows that it does.
Start a new chat when the job changes, with a useful handoff
Finishing an invoice fix and moving on to a staff scheduling feature is a reasonable point to start fresh. The old conversation may contain failed attempts and decisions that have nothing to do with the new job.
Before you leave it, save a short account of the current state. Include the files or objects changed, decisions still in force, checks that passed, and work still outstanding. Read the summary yourself. A summary that says “the integration is finished” is no help if the sending step hasn't been tested.
EXAMPLE HANDOFF
We're working in the development copy of the invoicing project. The preview is implemented on the invoice layout. The email workflow, schema, and privilege sets were left unchanged.
The preview was checked with a normal staff account and sample invoices, including one with no line items. No email was sent and no production service was called.
Next, review the preview in FileMaker Go. The last test covered FileMaker Pro only. Keep the existing invoice formatting and return the user to the original screen without changing data.
A fresh conversation doesn't reset a subscription allowance or erase API usage already incurred. It changes the conversation you're continuing. Whether it reduces the next request depends on what the tool loads and how much work must be repeated.
Compaction is useful, but check what survives it
Compaction generally replaces older conversation material with a shorter account of the work. It creates room to continue, but a summary can leave out a detail you still need.
Claude Code documents the contents of its context and its compaction behavior in How Claude Code works. Its persistent project instructions are one place to keep rules that should apply across sessions. Other tools have their own instruction files and loading behavior.
Keep those instructions readable and current. Put the everyday setup and important limits where the tool expects them, then point to longer references when necessary. Avoid turning the main instruction file into a record of every conversation you've had.
After a long session is summarized, check the few details you would hate to lose: which copy is being edited, what remains untested, and what the assistant is allowed to change. Ask it to confirm those before continuing a consequential task.
Check the tools you're loading before disabling them
Tool descriptions and tool results can take up context. The amount depends on the application, the connected servers, and whether definitions are loaded upfront or discovered when needed.
That last part matters. Current tools can defer some definitions, so advice claiming that every connected MCP tool always loads its complete description may be out of date. Both the Cursor discovery article and Claude Code's documentation describe loading tools as needed.
Use the context breakdown your application provides, if it has one. Remove connections you don't need for this project, but keep the tools needed to inspect and verify the work. Saving some input while losing the ability to run the relevant check isn't a useful trade.
Measure a finished task before buying a bigger plan
Pick a repeatable job and note the model, the starting context, the resulting usage, and whether the work passed review. Try one change at a time: a clearer request, a smaller attachment, or a fresh session at a natural stopping point.
Track the time you spend repairing the result as well. A cheaper model or shorter request hasn't saved much if you have to repeat the job with better information. Likewise, a larger context window won't stop an assistant from reading unnecessary material or repeating failed attempts.
Subscription limits and API billing are also different arrangements. Check which one your tool is using and whether extra spending is enabled. Anthropic's cost-management guide explains the distinction for Claude Code, including the limits of session cost estimates. Use your provider's account usage and billing records for the financial total.
You don't need to redesign your workflow overnight. For the next job, give the assistant a clear starting point, keep unrelated material out of the conversation, and save a useful handoff when you finish. Compare the result with what you were doing before. That will tell you more than a promised percentage from a token-saving tip.
If you're working through token usage in a FileMaker project, I'd be interested to hear which numbers your tool shows and what you were doing when they changed. Email me at alex@rgcdata.com. Please leave credentials and customer data out of any examples.
