Meridian Line's customs-compliance agent handles a steady, predictable stream of about 400 requests per minute around the clock during business hours, and the compliance team needs consistent low latency on every call because a slow response holds up cargo release. Which Foundation Model APIs purchasing mode best fits this traffic pattern?

Foundation Model APIs offer purchasing modes with different cost and latency profiles, so match the choice to the traffic pattern. Pay-per-token suits variable, bursty, or low-volume workloads because you do not provision capacity and cost tracks usage directly, but throughput and latency are shared across tenants and are not guaranteed to remain consistent under load. Provisioned throughput reserves dedicated model-serving capacity sized to a target throughput, making it the fit for Meridian Line’s steady, predictable, high-volume, latency-sensitive workload: consistent latency is the point of paying for reserved capacity. The claim that pay-per-token scales instantly to any burst describes elasticity, not a guarantee of consistent latency, and this traffic is steady rather than bursty. The claim that pay-per-token is always cheaper is also false: at sustained high volume, provisioned throughput is typically more cost-effective and predictable. The claim that tool calling makes provisioned throughput mandatory invents a requirement; tool calling is a model-capability question, not something determined by purchasing mode. Exam caveat: map steady, predictable, latency-sensitive, high-volume traffic to provisioned throughput, and bursty, unpredictable, low-volume traffic to pay-per-token. Practical check: compare the expected sustained requests per minute and latency needs with the capacity and guarantees available before choosing.