Changelogs: Week of June 15, 2026

This week's work expanded the PolarGrid network to its seventh data center, shipped country-aware routing across the full fleet, and added function calling and reasoning control to the SDK.

Los Angeles is live

PolarGrid now operates seven data centers across North America. The new Los Angeles node (lax-01) joins San Francisco and Vancouver on the West Coast, Dallas in South Central, and New York, Toronto and Montreal on the East Coast.

For applications serving users in Southern California — voice pipelines, real-time inference, streaming completions — requests now terminate at a local edge rather than routing north to San Francisco. The latency reduction is most pronounced for time-sensitive workloads: voice agents and interactive applications where every hop compounds. Los Angeles appears as a selectable region in the dashboard and playground dropdown. Health monitoring, latency-based routing, and automatic failover are active.

Country-aware routing

The PolarGrid intelligent autorouter now applies country-aware routing by default. When a request arrives, the intelligent autorouter evaluates healthy nodes within the originating country first. A cross-border hop only occurs when every in-country node is unavailable or degraded, in which case the nearest international node handles the request instead.

The practical effect is twofold. Latency improves for most requests, since in-country nodes are physically closer to callers. And traffic stays within its region of origin whenever the network can accommodate it — which matters for teams operating under data residency requirements or internal policies around cross-border data transfer. The behavior is automatic and applies to all inference requests. Regional pinning and explicit routing overrides remain available through the API for workloads that require them.

Function calling and enable_thinking

Tool and function calls are now surfaced in chat completions across both the JavaScript (≥ 0.9.1) and Python SDKs. Pass a tools array in your request, and when the model decides to invoke a function, the response includes a structured tool_calls object. Your application executes the call, returns the result as a tool role message, and the model continues. The interface follows the same shape as the OpenAI chat completions API, so existing tool-calling integrations require minimal changes to migrate.

A new enable_thinking parameter is also available for Qwen 3 models. Set it to true and the model enters an extended reasoning mode, working through the problem before producing a final answer. The default is false, which gives standard completion behavior — faster and appropriate for most production use cases. The toggle is useful for applications that mix routine requests with occasional tasks where depth matters: complex reasoning, multi-step planning, math. A single parameter controls the tradeoff at the request level rather than requiring separate model deployments.