AI Agent CRM Integration: What Switching Models Does to Your Cost per Lead

The agent captures the lead. What does each one cost?

A website agent that sends leads to a CRM does a small, repeatable job. A visitor asks for a demo or a quote. The agent asks a few qualifying questions, collects an email and the details sales needs, and calls the CRM API to create or update the contact. When it works, the salesperson opens a record with the full context instead of asking the visitor everything again.

Integration guides cover the plumbing: where to ask for contact details, how to map fields, how to test the API request. They rarely cover the model bill, or what happens to that bill and to your lead flow when you swap the model behind the agent. This post works through both with current list prices.

Every number below uses one workload. One conversation is one request in the calculator. It runs six model calls. Each call resends a 2,400-token system prompt and CRM field schema plus the conversation so far, which averages 1,600 tokens. Each call writes about 150 output tokens: a reply, extracted fields, or the API request body.

The success rates are assumptions chosen to show the method, not measurements. Prices are Standard list prices from the AICostBudget dataset, with no batch discount and no caching unless a section says otherwise. The table at the top of this page links each price to the provider's own page.

One conversation on four models

Cost per conversation is (24,000 × input price + 900 × output price) ÷ 1,000,000. Input is 96% of the tokens and most of the bill: on Sonnet 5.5, input is $0.048 of the $0.057. That matters later, because input is the part caching can cut.

The cards below run the same workload through the Model Switch Cost Calculator's pricing engine, so they update when a provider changes a price.

The token math says switch. The CRM says check first.

On tokens alone, Haiku 5.5 wins by a wide margin. It costs 5% of Sonnet 5.5 per conversation, so it only needs to succeed in 4.7% of conversations to match Sonnet's cost per successful lead at a 94% success rate. Any token-only comparison will tell you to switch today.

A lead agent is not a token-only problem. A conversation that ends without a valid CRM record is not just a wasted API call. It is a visitor who asked to talk to sales and never reached them. With the assumed rates, Sonnet 5.5 creates 18,800 complete records a month and Haiku 5.5 creates 17,600. The cheaper route loses 1,200 leads a month.

break-even lead value = saving per conversation ÷ capture-rate drop

Sonnet 5.5 → Haiku 5.5:  (0.057 − 0.00285) ÷ (0.94 − 0.88) = $0.90

So the switch saves $1,083 a month only if each lost lead is worth less than $0.90 to you. Turn the rule around and you get the question to ask before any switch: how many points of capture rate can the cheaper model afford to lose?

To find your lead value, divide the pipeline or revenue that came from agent leads last quarter by the number of those leads. Once that number reaches a few dollars, the decision no longer turns on token price. It turns on whether the cheaper model fills the CRM fields as reliably. The mid-priced models face the same test with a smaller margin: at $50 a lead, Gemini 3.8 Flash and GPT-5.4 mini can each afford to lose about 0.07 points.

Define a successful lead before you test

A capture rate is only useful if every model is graded by the same rule, and the rule is something your logs can check without a human reading transcripts. For a CRM agent, three checks cover it:

• The CRM accepted the request. The API call returned a 2xx status. Log the status code next to the conversation ID.
• The record is complete. Every required field has a valid value: a real email format, a team size that is a number, and a next step from your allowed list (demo, quote, callback).
• The record is not a duplicate. A returning visitor should update the existing contact, not create a second one.

The third check is easiest to pass by design. Use your CRM's upsert or dedupe feature rather than a plain create call. HubSpot's contacts API guide describes a batch upsert endpoint that can use email as the identifier, with one limit: partial upserts are not supported when email is the identifier.

• Step 1. Pick 200 to 500 real past conversations, or replay recent visitor messages against each model with the same system prompt and tools.
• Step 2. For each run, record input and output tokens from the usage field of every model response, and add them up per conversation.
• Step 3. Grade each conversation with the three checks above against a test CRM or sandbox, never your live pipeline.
• Step 4. Your capture rate is passing conversations ÷ conversations started. Compare it across models along with the measured tokens, because models write different amounts of output for the same prompt.

Two cheaper moves that do not risk leads

If the test shows the cheaper model loses leads, you still have options that cut the bill without changing who answers the visitor.

The first is prompt caching. The 2,400-token system prompt and schema are identical on all six calls. With Anthropic's prompt caching, the first call writes that prefix at 1.25 times the input price, and the next five read it at the cached price, as long as each turn arrives within the default 5-minute lifetime. Per conversation, that is 2,400 cache-write tokens and 12,000 cached input tokens, half of all input.

Caching takes Sonnet 5.5 from $1,140 to $708 a month, 38% less, with the same model and the same capture rate. Do this before testing a model switch, then compare both models with caching on.

The second move is routing. Let Haiku 5.5 handle every conversation, and send a conversation to Sonnet 5.5 only when your checks fail, for example when the extracted email is invalid or the CRM call returns an error. If 10% of conversations need that second pass and you rerun the whole conversation, the bill is $0.00285 + 10% × $0.057 = $0.00855 per conversation, or $171 a month. That keeps $969 of the $1,083 saving, as long as the second pass recovers the leads Haiku missed.

Rerunning the whole conversation is the expensive case. Retrying only the failed field extraction costs less. For the full route math, see when a fallback model should become the primary, and price your route in the Retry & Fallback Cost Calculator.

Run it on your own agent and save the workload

• Step 1. Open the Model Switch Cost Calculator. Set Current model to the model your agent runs today and Target model to the candidate.
• Step 2. Enter your measured Input tokens / request and Output tokens / request per conversation, and your conversations as Requests / month. If you cache the prompt prefix, fill Cache-write tokens / request and Cached input share.
• Step 3. Open Compare cost per successful task. Enter your Current success rate and Alternative success rate from the test, and write your three checks in Acceptance rule so the assumption travels with the numbers.
• Step 4. Read the Break-even alternative success rate, then do the lead-value check from this post: saving per conversation ÷ capture-rate drop.
• Step 5. Name the workload, for example "Website lead agent", and choose Save workload. Saved workloads stay in your browser. If either model's price changes after you save, or a model gets a retirement notice, the saved workload is marked Needs attention and opens with the new monthly cost.

If your agent also answers support questions, the customer support chatbot cost walkthrough covers that traffic. For comparing routes by completed work rather than API calls, see cost per successful task.

What this math leaves out

• Lead quality. Two records with the same fields can lead to different conversations with sales. The capture rate counts complete records, not good ones.
• Conversation length. Visitors who ask more questions run more calls. Use the average from your logs, and check the longest 5% separately.
• CRM reads. If the agent looks up existing records and puts them in the prompt, input tokens grow with every lookup.
• Integration cost. Automation tools and CRM API plans have their own pricing. This post covers the model bill only.
• Price changes. Every price here is a list price checked in October 2026. Recheck before you commit, or save the workload and let the calculator flag changes.

Price changes are logged with dates and sources on the model price monitor, and the methodology page explains how each price is verified. Your provider's invoice is the final word on what you paid.

FAQ