
Until recently, an EDA budget was a negotiated number that stayed put for the length of a contract. AI agents change that, because they add two bills that move with use: model tokens, and the extra tool licences those agents consume when they run simulations by the hundred. Vendors and customers are now arguing openly about both.
The public debate tends to quote a single token price, and a single price is no help to a manager planning next year's spend. What a team needs is a model it can fill in with its own numbers, covering the whole cost of an agent and the amount of engineering capacity that cost has to buy back. This post builds one for a 20-person team, then tests where it breaks.
Key takeaways
- Budget four lines: tokens, extra licences and compute, agent subscriptions, and engineer time spent reviewing agents. Tokens are the most visible of the four, and may not be the largest.
- Price per token means little without the token mix. On published list prices, the same work can cost about 3.5 times more when prompt caching fails.
- Synopsys showed one use case with 5 to 10 times more VCS and Verdi licences. If your subscription capacity runs out, that line can overtake the token bill.
- Vendor token efficiency claims range from about 2 times to 10 times, on different workloads and mostly undisclosed baselines. Benchmark them on your own regression before you put them in a budget.
- The useful output of the model is a break-even figure: the share of team capacity the agents must return to pay for themselves.
Why this became a budget line
The pressure is now out in the open. At a Design Automation Conference roundtable reported by Semiconductor Engineering, Synopsys's Anand Thiruvengadam said customer talks had moved away from open-ended budgets towards limits on tokens or dollars for each engineer, and Harrison Balistreri of ChipAgents projected 100 billion tokens per engineer per year within 18 months, based on trends in his company's products. In August, Ankur Gupta of Siemens EDA told a briefing in Seoul that engineers at large companies were restricting or suspending LLM use because token budgets had become too high, according to The Elec.
These are remarks and not market data, and the speakers all sell something in this space. They do show that the question has reached the budget holders.
Who bills what
Before modelling anything, work out which invoice each cost lands on. The two largest EDA vendors have described arrangements in which the LLM bill may not come from them at all.
| Cadence | Synopsys | |
|---|---|---|
| Agents | CEO Anirudh Devgan, February 2026: priced like a virtual engineer, as extra business on top of base tools | Subscription to agents, on the Synopsys platform or inside the customer's own |
| Base tools | CFO John Wall: multiyear subscription stays at the core, with usage-based pricing added for incremental capacity | Subscription or consumption, and CEO Sassine Ghazi said customers currently lean towards subscription |
| LLM cost | Wall, October 2026: customers can use their own LLM infrastructure and license the design agents and orchestration | Options include the customer's own AI platform, or GPT-Synopsys taken from OpenAI, with an outcome-based revenue share between OpenAI and Synopsys |
Neither company has published rates in the sources we read, so the commercial terms have to come from your own quote. Ghazi also made a point that buyers will recognise: customers do not know how much capacity they will need, and are reluctant to commit to it for three years.
The model
Four lines, in dollars per month:
- Tokens: millions of tokens multiplied by a blended price, worked out job by job.
- Extra licences and compute: baseline tool spend, multiplied by the share of the workload agents touch and by the increase in usage.
- Agent subscriptions: from your quote.
- Review time: the share of team hours spent steering and checking agents, at loaded cost.
The blended price is where most estimates go wrong. Agent sessions resend their history on every turn, so most of what they consume can be cached input, charged at a fraction of the normal rate. Here are the vendors' own list prices, as published on 5 November 2026, per million tokens. Dearer models exist at $10 input and $50 output.
| Tier used here | Example models | Input | Cached input | Output |
|---|---|---|---|---|
| Large | Claude Opus 5.5 | $4.00 | $0.20 | $20.00 |
| Mid | Claude Sonnet 5.5, gpt-6.1-sol | $2.00 | $0.10 | $10.00 |
| Small | Claude Haiku 5.5, gpt-6-luna | $0.10 | $0.01 | $0.50 |
Now assume a mix of 90% cached input, 5% fresh input and 5% output. This split is our assumption, so measure your own. For the mid tier, 0.90 × $0.10 + 0.05 × $2.00 + 0.05 × $10.00 gives $0.69 per million tokens. The same mix costs $1.38 on the large tier and $0.039 on the small one. We have left out the premium that some providers charge for writing to the cache, and the higher Haiku 5.5 rate on prompts over 100,000 tokens.
A worked example: a 20-person verification team
Every volume, salary and licence figure below is an illustrative assumption, not data from any company. Only the token prices above are published.
| Job | Monthly volume | Million tokens | Tier and price | Monthly cost |
|---|---|---|---|---|
| Interactive assistance | 20 engineers × 20 days × 30 | 12,000 | Mid, $0.69 | $8,280 |
| Nightly failure triage | 22 nights × 500 failures × 0.2 | 2,200 | Small, $0.039 | $86 |
| Deep debug on failure clusters | 22 nights × 20 clusters × 15 | 6,600 | Large, $1.38 | $9,108 |
| Coverage closure campaigns | 4 campaigns × 10 agents × 200 | 8,000 | Mid, $0.69 | $5,520 |
| Testbench and RTL generation | 2 campaigns × 50 runs × 100 | 10,000 | Large, $1.38 | $13,800 |
| Tokens | 38,800 | $36,794 |
There is one public number to test this against, and it is a vendor's figure about its own product. The interactive line comes to $20.70 per engineer per active day. Anthropic's Claude Code documentation reports an average of around $13 per developer per active day across enterprise deployments, and below $30 for 90% of users. We found no independent figure, and those users are likely to be mostly software developers, so treat it as a rough check and nothing more.
Next, the other three lines, with a loaded engineer cost of $250,000 a year, which makes team payroll $416,667 a month:
| Line | Arithmetic | Monthly cost |
|---|---|---|
| Tokens | From the table above | $36,794 |
| Extra licences and compute | $60,000 baseline × 20% of workload × (5 − 1) | $48,000 |
| Agent subscriptions | 2 agents × $4,000 | $8,000 |
| Review time | 10% of payroll | $41,667 |
| Total | $134,461 |
Divide the total by payroll and you get the break-even: agents must return about 32% of the team's capacity, or roughly 6.5 engineers' worth of work, to cover their cost. Schedule gains could justify a higher figure since, in our judgement, a slip near tape-out can cost far more than a month of tokens. Write that value down separately so that it does not hide a weak productivity case.
Notice the shape of the result. Tokens are 27% of the total here. The token bill has the most public attention, yet in this example more money goes on licences and on review time.
Where the model breaks
Change one assumption at a time and watch the break-even, which starts at 32%.
| Scenario | Changed line | New total | Break-even |
|---|---|---|---|
| Licences stay inside existing subscription capacity | Licences $0 | $86,461 | 21% |
| Small tier carries 98% of tokens, large tier 2% | Tokens $2,554 | $100,221 | 24% |
| A 5 times token efficiency claim holds in full | Tokens $7,359 | $105,026 | 25% |
| Every job runs on the large tier | Tokens $53,544 | $151,211 | 36% |
| Review takes 20% of team time | Review $83,333 | $176,127 | 42% |
| Licence usage rises 10 times on that workload | Licences $108,000 | $194,461 | 47% |
| Caching fails: 95% fresh input, 5% output | Tokens $127,944 | $225,611 | 54% |
| Team reaches 100 billion tokens per engineer per year, same job mix | Tokens $158,049 | $255,716 | 61% |
Three lessons follow. First, routing and vendor efficiency are worth having, but even a near-total cut in tokens takes only about 8 points off the break-even here. The 98% row is our own what-if. Whether a small or open model can carry that share of your flow is an empirical question, and our small tier stands in for those models only on price.
Second, cache discipline matters more than model choice in this table. Long pauses and changing prompt prefixes can both cause misses, so this is an engineering problem as well as a purchasing one.
Third, the last row shows how much rides on usage growth. On the mid and large blended prices, 100 billion tokens works out at $69,000 to $138,000 per engineer per year, a large share of our illustrative $250,000 engineer. We do not know whether Balistreri's count includes cached tokens, which would move the dollar figure a long way.
Reading the efficiency claims
| Vendor | Claim | What we could not establish |
|---|---|---|
| Siemens | 5 to 10 times lower token costs, on library characterisation with Solido | The baseline |
| Cadence | Up to 5 times token efficiency for Maestro models against general-purpose foundation models, described as initial results | Workload and model compared |
| Synopsys | 2 times better token efficiency, among results Synopsys published for a product not yet generally available | Workload and customer |
These are company claims and they cannot be compared with each other. A token efficiency number also says nothing about quality, so a run that uses fewer tokens but needs a second attempt may cost more. The fair test is cost per accepted outcome on your own design: per closed coverage point, per correctly root-caused failure, per testbench that passes review.
Controls worth setting up first
- Attribute spend to the regression and the agent. A DVCon paper by Ajith Jose of Dhenara points out that standard EDA infrastructure has no concept of LLM cost. The paper reports that a small subset of failing tests produced most of the token spend because of deep stack traces, and that selective truncation cut cost with no effect on triage. The author sells this product, so treat it as one vendor's experience, though the check is cheap to repeat. Good logs help people as well as models, as we covered in Designing for Debug.
- Filter logs before the model sees them. A filter that passes on only the failing lines costs almost nothing to run, and it shrinks every later turn as well.
- Use soft caps that downgrade. Stopping a nightly run at a hard limit loses the night. Moving the rest of the run to a cheaper model keeps it going.
- Batch what can wait. Anthropic and OpenAI both list batch prices at half of standard. First-pass triage suits this, while tightly looping agents usually do not.
- Limit parallel agents deliberately. Anthropic's documentation, again a vendor describing its own tool, says agent teams use about 7 times more tokens than standard sessions when teammates run in plan mode. Parallel work has a price on both the token and the licence lines.
- Set a licence ceiling as well as a token ceiling. In our view an agent will use whatever compute and licences it can reach, so nobody else will apply the limit for you. The old question of a faster simulator or more compute now has a third option, and a third bill.
Before you sign: six questions
- Who bills the LLM usage, and can we bring our own model or inference?
- What does an agent subscription include, and what happens above the allowance?
- Do licences called by an agent draw on our existing subscription, or are they metered?
- Can we see tokens and licence hours per run, in a form we can export?
- What baseline sits behind your efficiency figure, and can we repeat it on our regression?
- What are the rates if we use twice, or ten times, the volume we expect?
Agree the budget checkpoints early as well. We expect spend to peak around verification closure, close to the tape-out gate, though that is our judgement and not measured data. Our SoC lifecycle on The Semiconductor Hub shows where those stages and gates fall in a programme.
FAQ
Is an EDA token the same as an LLM token?
No, and it is worth checking which one a contract means. A model token is a unit of text a model processes. In EDA licensing, a token is usually a prepaid unit that unlocks tool capacity. Ask the vendor to define the word in writing.
Should a team run open models on its own GPUs?
Possibly, for high volumes or strict data rules, but the saving is not simply the token price. You then carry the hardware, the power, the operations staff and any quality gap. Compare cost per accepted outcome, as above.
Will token prices fall and solve this?
We would not plan on that alone. Published prices can move in either direction between model generations, and usage can grow faster than prices fall. In our view, agents also tend to fill the capacity they are given, so keep the volume assumption separate from the price assumption. The electricity behind those tokens is a separate question, which we looked at in The Hidden Cost of Agentic AI.
Sources
- Cadence Q4 2025 earnings call, 17 February 2026, and Q3 2026 earnings call, 26 October 2026, third-party transcripts, not checked against company copies.
- Cadence, Maestro AI model portfolio announcement, October 2026, as reported by Engineering.com.
- Synopsys, "Synopsys Details Growth Strategy and Long-term Financial Model at 2026 Investor Day", 30 September 2026, and Investor Day 2026 transcript, third-party copy, not checked against a company copy.
- Synopsys, "Synopsys Powers Autonomous Engineering with Long-Horizon Agents and Autopilot Platform", 28 September 2026, and Brendan Burke, Futurum, "Synopsys Autopilot Aims to Consolidate Chip Design Around One Stack", 28 September 2026, for the 2 times figure.
- Siemens, press release on self-verifying agentic AI workflows for EDA with NVIDIA, 26 July 2026.
- Liz Allan, "Token Costs Are Becoming The New EDA Budget Battle", Semiconductor Engineering, 9 September 2026.
- The Elec, "Siemens EDA Says AI Can Cut Chip Design Time by Up to 10x", 11 August 2026.
- Ajith Jose (Dhenara), "Passive Token Accounting For Cost-Aware LLM Assistance In Continuous SoC Verification Workflows", DVCon U.S. 2026.
- Anthropic, "Pricing" and Claude Code "Manage costs effectively" documentation, and OpenAI, API pricing documentation, all read on 5 November 2026.
The worked example uses illustrative numbers apart from the list prices, which change often. Vendor figures are the companies' own claims and targets, as published on the dates shown.
Disclosure: this article was drafted with Claude, an AI model made by Anthropic, and reviewed by Murugavel Ganesan. Anthropic's prices and usage figures appear above, so read them as figures from a company with an interest in the subject.


Your comments will be moderated before it appears here.