AI Tokens in CAD: What Engineers Using LLMs and Coding Agents Need to Know

Skip to:

• What is an AI Token
• Context is the Agent’s Working Memory
• Do Different AI Models Consume Different Numbers of Tokens?
• Why Token Consumption Matters for AI in CAD
• How MCP Affects Token Usage
• Use Separate Sessions for Separate Projects
• Use Plan Mode Before Expensive Work
• Compact Long Sessions at Meaningful Milestones
• Caching, Compaction, and Clearing Are Diferent
• 8 Tips for Engineers Using AI with CAD

Many AI capabilities built directly into CAD software manage their model usage behind the scenes. Engineers generally do not need to think about tokens when using these self-contained features.

The situation changes when engineers connect their preferred large language model (LLM) or coding agent – such as Claude, Codex, or Gemini – to a CAD system. In these workflows, engineers are also managing an AI session that may accumulate prompts, code, CAD information, tool definitions, MCP results, errors, and design decisions.

This is when token consumption becomes an engineering consideration.

Most people assume an AI agent processes only their latest prompt. In a working session, however, it may also process previous messages, project instructions, code, engineering data, available tools, tool results, and earlier decisions.

In other words, your prompts can compound.

Understanding this can help engineers choose the right model, structure their sessions, control context growth, and get better results from AI-assisted CAD.

What is an AI Token?

A token is a small unit of information processed by a large language model. It might be a complete word, part of a word, punctuation, a number, or a fragment of code.

Engineers do not need to calculate tokens manually. The important point is that everything the model reads and writes can consume tokens, not just the prompt entered by the user.

In an AI-assisted CAD workflow, tokens may be used for:

• The current prompt
• Previous prompts and responses
• System and project instructions
• Source code or FeatureScript
• CAD parameters, metadata, and feature information
• MCP tool descriptions and results
• Errors, test results, and debugging history
• The model’s response and reasoning

The short prompt visible on the screen may be only a small part of the agent’s actual workload.

Context is the Agent’s Working Memory

The information available to the model during an interaction is called its context. The maximum amount it can hold is its context window.

Think of an AI agent as an engineer working from an expanding project binder. Every prompt adds pages. Reading code, calling an MCP tool, encountering errors, and making design decisions can add more.

When you ask the next question, the agent may need to review much of that binder again.

For example, if the first interaction contains 1,000 tokens and the next prompt adds 200, the second interaction may process approximately 1,200 tokens. Add another 300, and the working context may reach 1,500.

This is a simplified illustration, not a billing formula. Actual systems may cache repeated information, summarize older history, remove obsolete tool results, or retrieve only the most relevant material.

Nevertheless, the basic principle remains: As a session grows, each additional interaction can become heavier.

A large context window is useful, but more context is not always better. Old experiments, conflicting instructions, irrelevant files, and oversized tool results can make important information harder to distinguish.

Good context management is about relevance – not simply minimizing tokens.

Do Different AI Models Consume Different Numbers of Tokens?

Yes. The same input may not produce exactly the same token count across different models or providers.

Models can also vary in:

• Context-window size
• Reasoning-token usage
• Response length
• Number of tool calls
• Caching and compaction behavior
• Input and output token pricing

The largest difference is often not how the original prompt is divided into tokens, but what happens afterward. A powerful reasoning model may consume more tokens during one interaction but complete the task with fewer mistakes and fewer follow-up prompts. A less expensive model may cost less per token but require more iterations.

The right engineering metric is not tokens per prompt. It is the total cost and token consumption required to produce a correct result.

Smaller or faster models may be sufficient for documentation, routine edits, or clearly defined operations. Complex FeatureScript development, architectural decisions, and difficult debugging may justify a stronger reasoning model.

Even when token usage is included in a subscription rather than billed directly, it can still affect usage limits, response time, and how quickly the context window fills.

Why Token Consumption Matters for AI in CAD

CAD and engineering workflows can accumulate considerable context. An agent may need to understand requirements, design parameters, feature definitions, code, metadata, manufacturing constraints, tool results, and regeneration errors.

The agent does not necessarily receive an entire geometric model as text. What enters the context depends on the CAD system, AI client, integration, and tools being used. However, extracted parameters, design information, custom feature code, and tool results can all consume tokens.

A short request such as “change the thread termination” may therefore require the agent to understand the feature, its code, earlier requirements, previous tool calls, and debugging history.

For engineers connecting an LLM to CAD, token management affects more than cost. It can also affect speed, focus, and result quality.

How MCP Affects Token Usage

Model Context Protocol (MCP) gives AI agents a standard way to discover and use external tools. An MCP server might allow an agent to inspect engineering information, generate FeatureScript, call an API, or perform an action in a CAD system.

MCP does not cause conversation history to compound. However, it can add information to the context through:

• Tool names and descriptions
• Instructions defining how tools work
• Requests sent to tools
• Information returned by tools
• Decisions based on those results

The amount varies by implementation. Some AI clients load tool information only when needed, while others may expose more upfront.

Focused MCP calls are generally more efficient than returning everything and expecting the model to sort through it.

Request only the features, parameters, errors, or records relevant to the current task rather than introducing unrelated project data.

Use Separate Sessions for Separate Projects

One of the easiest ways to control context is to avoid mixing unrelated work.

Use one AI session per project – or per clearly defined workstream. Starting an unrelated task in the same session forces the agent to carry information that no longer helps. It can also cause requirements from one project to influence another.

A useful rule: One project – or one clearly defined workstream – per session.

This is especially valuable with Onshape and FeatureScript MCP. Separate sessions might simultaneously:

• Develop a custom thread feature
• Create a configurable component
• Investigate another modeling problem
• Test and document completed work

Because Onshape is cloud-native, independent activities do not need to be forced through one long, serial AI conversation. When tasks do not depend on one another, they can proceed in parallel.

Separate sessions can reduce unnecessary context while also enabling parallel engineering work.

Parallelism works best when each session has a clear objective and ownership. Sessions changing the same code or making competing design decisions must still be coordinated.

Use Plan Mode Before Expensive Work

Plan Mode allows an AI agent to investigate and propose an approach before implementation. It may consume additional tokens initially, but it can prevent the agent from choosing the wrong architecture, modifying the wrong files, or spending many turns correcting a misunderstanding.

Think of it as spending a few tokens to avoid wasting thousands.

Planning is most valuable when the work affects multiple features or systems, requirements are incomplete, several approaches are possible, or a mistake would be expensive to reverse.

For a simple edit, formal planning may add unnecessary overhead.

A dedicated Plan Mode is different from asking the model to write a plan. A normal prompt may produce a plan, but it may not activate the product’s read-only safeguards.

Current commands include:

• Claude Code: /plan
• Codex: /plan
• Gemini CLI: /plan

If the tool does not provide a dedicated Plan Mode, use a prompt such as:

“Review the objective, identify the relevant files and tools, list any assumptions or risks, and propose a short implementation and validation plan. Do not make changes yet.”

Compact Long Sessions at Meaningful Milestones

Compaction replaces detailed older conversation history with a shorter summary of what still matters.

Returning to the binder analogy, compaction creates a project brief that includes the requirements, key decisions, completed work, test results, and remaining tasks.

Compact a session:

• After completing a major phase
• Before beginning the next phase
• After resolving a long debugging sequence
• When the session contains many abandoned approaches
• When the context window is becoming full

Current commands include:

• Claude Code: /compact
• Codex: /compact
• Gemini CLI: /compress

Use the product’s actual compact or compress command when available.

Simply asking an agent to “compact this session” may produce a written summary without actually removing the older conversation from the active context.

When the product accepts compaction instructions, tell it what to preserve:

“Preserve final requirements, design decisions, relevant files, working code, test results, unresolved issues, and the next action. Remove abandoned approaches and repetitive discussion.”

Compaction can omit details, so critical requirements and decisions should also be maintained in a durable project document.

Caching, Compaction, and Clearing Are Different

Caching lets the AI platform reuse previously processed information. It may reduce cost or latency, but cached content can still occupy the context window.

Compaction summarizes older context so the session can continue with less accumulated information.

Clearing or starting a new session creates fresh context and is usually best when changing to an unrelated task.

Caching is generally handled by the platform. Compaction and session separation are the controls users are more likely to manage directly.

The Engineer’s Mental Model

Tokens are not merely the words entered in a prompt. They represent the information an AI system may process or generate – including conversation history, code, CAD information, tool descriptions, and MCP results.

The goal is not to use the fewest possible tokens. The goal is to provide the minimum relevant context that still allows the AI agent to complete the engineering task correctly.

Manage AI context like any other engineering resource: give it a clear purpose, keep it organized, and do not carry material that no longer contributes to the result.