Using OpenAI for customer support: which model, what it costs, how to wire it up

The lineup, ranked for support

OpenAI's public models break into three useful buckets for customer support. Skip everything else.

Per-ticket costs assume a typical 1,800-input / 220-output token support ticket at mid-2026 list prices. For the full math see the BYO LLM cost guide.

Picking the default model

For 80% of teams, the right answer is GPT-4o-mini as the default for all agents, with a routing rule that escalates to GPT-4o for one specific agent if you want it.

Three reasons GPT-4o-mini wins by default:

• It's cheap enough to never think about. $9/month on 5,000 tickets isn't a budget conversation; it's a rounding error.
• It's fast. Median response under 800ms with streaming, well under the 2-second threshold visitors notice as “slow.”
• It's tuned for instruction-following. Modern RAG support prompts (“answer only from the context, cite sources, escalate if unsure”) are obeyed cleanly.

When to upgrade to GPT-4o

GPT-4o is roughly 7x the per-ticket cost of mini and is genuinely smarter on:

• Drafting refund / escalation messages. The difference between a generic apology and a specific one shows up here.
• Multi-thread context. If you have visitors with long conversation histories, 4o handles 50+ message threads more coherently.
• Subtle policy reasoning. “Does this customer qualify for the loyalty discount given their order history?” Mini guesses; 4o reasons.

Practical pattern: route “Refunds” and “Escalations” agents to GPT-4o, keep everything else on mini. Average bill stays close to mini's, the high-stakes traffic gets the smarter model.

Skip the o-series unless you have a specific reason

o1 and o3-mini are reasoning models: they think for several seconds before responding. Excellent for math, coding, and multi-step logic. For customer support they're typically overkill and their 5-30 second latency feels broken to a visitor expecting an instant reply.

The legitimate use case: a backend agent that runs offline (not in the chat panel) to triage incoming bug reports, classify intent, or summarise long threads for a human pickup. There, the reasoning is worth the latency.

Wiring your OpenAI key into OpenAgent

1. Get an API key from platform.openai.com/api-keys. A standard project key is fine.
2. In OpenAgent, go to Settings → Providers → Add provider. Pick OpenAI. Paste the key. The platform encrypts on submit; the key never lands plaintext anywhere.
3. For each agent (under Agents → Edit) pick the model from the dropdown. GPT-4o-mini is the default suggestion.
4. Optional: set a per-agent fallback model. If OpenAI returns a 429 (rate limited), OpenAgent retries on the fallback before showing the visitor an error.

Azure OpenAI variant

If you're in an Azure-committed enterprise, use Azure OpenAI instead. The API surface is identical; only the base URL changes. In OpenAgent, pick OpenAI-compatible endpoint as the provider, paste the Azure deployment URL and key. Functionally identical from your end; data residency follows Azure's region configuration.

Watch-outs specific to OpenAI

• Rate limits matter at spikes. Default tier limits accommodate a few thousand requests per minute. If you spike (Black Friday, product launch), buy more tier headroom before the event, not during.
• Prompt caching saves real money. OpenAI's prompt-caching feature discounts repeated input tokens by 50%. OpenAgent uses it automatically for the static parts of system prompts; if you write your own prompts make sure the long static bits come first.
• Latency varies by region. The api.openai.com endpoint is US-east. If your visitors are mostly Asian, expect 200-400ms of additional latency. Azure OpenAI in your region is materially faster.

Bottom line

GPT-4o-mini as the default, GPT-4o for the high-stakes 20%, skip the o-series for live chat. Wire it in five clicks. Pay OpenAI directly. The chat platform is software, not a token reseller.