Whats new for the week for 10-12-26

fern/assistants/versioning/traffic-splitting.mdx

@@ -1,24 +1,18 @@
 ---
 title: Traffic splitting
-subtitle: Roll out assistant versions gradually with canary releases and experiments
-description: Split live call traffic between published assistant versions by percentage, so you can canary a new version, run experiments, and roll back instantly.
+subtitle: Roll out assistant versions gradually with canary releases and tests
+description: Split live call traffic between published assistant versions by percentage, so you can canary a new version, run tests, and roll back instantly.
 slug: assistants/versioning/traffic-splitting
 ---
 
-<Note>
-**Beta.** Traffic splitting must be enabled for your Vapi organization. Request access through the [beta access form](https://forms.gle/6EfEcCFxvxJTZHDs8).
-
-The beta includes percentage splits across published versions, sticky routing for repeat callers, the dashboard traffic editor, and the API, which also returns the full history of allocation changes. It does not yet include per-version call metrics, side-by-side version comparisons, or a dashboard view of past splits. To compare versions today, use each call's `assistantVersion` field, which records the version that handled the call and is also a column in call exports.
-</Note>
-
 Traffic splitting routes a percentage of an assistant's live calls to each published version you choose. Instead of every call moving to a new version the moment you publish, you decide how much traffic the new version takes, watch how it behaves, and finish or cancel the rollout on your own schedule.
 
 ## Why split traffic
 
 Publishing an assistant changes what every caller hears. A prompt rewrite that reads well can still greet customers the wrong way, mishandle a transfer, or cause regressions in edge cases that review missed. Traffic splitting turns that all-or-nothing moment into a controlled rollout:
 
 - **Canary releases**: Send a small share, such as 10%, of calls to the new version. If its calls look healthy, gradually raise the share to 100%. If they do not, remove it so the previous version immediately takes back the traffic.
-- **Experiments**: Run two versions side by side at 50/50 and compare their transcripts, call outcomes, and analysis before committing to either.
+- **Tests**: Run two versions side by side at 50/50 and compare their transcripts, call outcomes, and analysis before committing to either.
 - **Staged parking**: Publish a version at 0% so it exists in history and is callable by version, without routing any live traffic to it until you are ready.
 
 ## How routing works
@@ -68,7 +62,7 @@ The traffic pill in the assistant header shows where calls route now. Select the
 
 **An urgent fix during a rollout.** Remember that an explicit split pins traffic: publishing the fix does not route calls to it until you update the split. Publish at 100% if the fix should take everything, or add the fix's version to the split at the share you want.
 
-**Comparing versions fairly.** Give the candidates equal shares and let repeat-caller affinity keep each customer's experience consistent while the experiment runs.
+**Comparing versions fairly.** Give the candidates equal shares and let repeat-caller affinity keep each customer's experience consistent while the test runs. To review each version's calls, filter your call logs by assistant version in the assistant's Logs tab; each call also records its version in the `assistantVersion` field, which is a column in call exports.
 
 ## Splitting via the API
 

fern/assistants/versioning/versioning-assistants.mdx

@@ -110,6 +110,8 @@ The new version includes the tool version selections saved with the restored ass
 - **Inbound calls** use the assistant's current published version. You cannot select another version for an inbound call.
 - **Outbound and web calls** use the current published version by default. To use a specific published version, pass `assistantVersion` with `assistantId` in the [create call request](/api-reference/calls/create).
 
+Each call records the version that handled it. In the assistant's Logs tab, filter your call logs by assistant version to review a specific version's calls, and `assistantVersion` is included in call exports.
+
 ## Next steps
 
 <CardGroup cols={2}>

fern/changelog/2026-10-12.mdx

@@ -0,0 +1,16 @@
+# What's New: Week of October 12, 2026
+
+1. **Traffic splitting**: You can now [split assistant traffic](/assistants/versioning/traffic-splitting) across published versions by percentage when you publish, so you can canary a new version and roll back instantly, with a live traffic view in the assistant header.
+2. **Version-aware call logs**: You can now filter your call logs by [assistant version](/assistants/versioning) in each assistant's Logs tab.
+3. **GPT-Live keypad input and Google/Slack tools (Beta)**: [GPT-Live](/gpt-live/overview) calls can now accept incoming keypad (DTMF) input on phone calls, and Google Calendar, Google Sheets, and Slack tools now run on the GPT-Live reasoner.
+4. **Squad builder refresh**: Selecting a squad assistant now opens the assistant's settings in a side panel on the right. Options and settings for the [squad](/squads) are now in the Talk menu and the More actions (⋮) menu, and you can add an assistant from the left sidebar.
+
+## New Models
+
+1. **DeepSeek Flash**: DeepSeek's [`deepseek-flash`](/providers/model/deepseek) model is now available for assistants when you connect your DeepSeek account.
+
+## Fixes and Improvements
+
+1. **Call log playback**: In call detail you can now click a message to play it, with new waveform view options.
+2. **Krisp denoiser**: Fixed Krisp failing at a 24 kHz sample rate, fixed denoised audio sometimes sounding stretched on websocket calls, and denoiser failures now appear in the call log.
+3. **Simulations**: Fixed an issue where simulation runs could get stuck reconnecting while catching up on live progress.

fern/gpt-live/configuration.mdx

@@ -38,7 +38,7 @@ GPT-Live supports a different set of features from Vapi's other voice architectu
 | Outgoing DTMF | Supported on SIP using RTP DTMF. Pass digits as a string, for example `"0011*#"` |
 | Outgoing DTMF on Twilio, browser, or raw WebSocket calls | Not supported |
 | SIP INFO DTMF | Not supported |
-| Incoming keypad collection | Not supported. Leave `keypadInputPlan.enabled` disabled |
+| Incoming keypad collection | Supported on native Twilio and Vapi SIP. Enable `keypadInputPlan` |
 
 ### Tools
 
@@ -47,7 +47,8 @@ GPT-Live supports a different set of features from Vapi's other voice architectu
 | `function`, `apiRequest`, `mcp` | Supported. Called by the reasoner |
 | `endCall` | Supported |
 | `transferCall`, `dtmf` | Supported on the connections listed above |
-| Other tool types, including the Query tool, handoff, SMS, voicemail, and integration tools | Not supported. Use a function, API request, or MCP tool instead |
+| Google Calendar, Google Sheets, and Slack tools | Supported. Run on the reasoner. GoHighLevel and other integration tools are not supported |
+| Other tool types, including the Query tool, handoff, SMS, and voicemail | Not supported. Use a function, API request, or MCP tool instead |
 
 Give tools unique names. Classic tool messages, such as request-start messages, aren't spoken. Guide what the assistant says while work runs in the speaker prompt.
 

fern/gpt-live/migrate.mdx

@@ -19,7 +19,7 @@ Some features don't carry over. If your assistant depends on one of these, plan
 - **Squads and assistant handoffs** aren't supported. A squad becomes one assistant, as described [below](#from-a-squad).
 - **Model and voice fallbacks** must be removed. GPT-Live can't be a fallback model either.
 - **Exact or prerecorded speech** isn't available. GPT-Live generates all of its speech, including the greeting.
-- **Keypad input** from callers isn't supported.
+- **Keypad input** from callers works on native Twilio and Vapi SIP calls, and isn't available on browser or WebSocket calls.
 - **Knowledge bases and the Query tool** aren't available. Use a function, API request, or MCP tool for retrieval.
 - **Transfers** are blind only, on native Twilio and Vapi SIP calls. **Native Telnyx and Vonage** numbers aren't supported.
 
@@ -165,7 +165,7 @@ If the reasoner prompt grows to cover several distinct procedures, group them in
 | Idle-message hooks with `say.prompt` | Keep them. See [When the caller goes quiet](/gpt-live/design#when-the-caller-goes-quiet) |
 | Idle-message hooks with `say.exact` | Accepted, but the text is spoken as generated speech, so the words may vary and verbatim playback isn't guaranteed. Rewrite them with `say.prompt` |
 | Greeting | A text `firstMessage` works and is spoken as generated speech. Audio greetings and generated first-message mode aren't supported |
-| Keypad input plan | Must be disabled |
+| Keypad input plan | Supported on native Twilio and Vapi SIP. Not available on browser or WebSocket calls |
 | Start and stop speaking plans, `temperature`, `maxTokens` | No effect |
 | Structured outputs, call analysis, scorecards | Keep them. See [Test and improve](/gpt-live/testing#watch-production-calls) |
 

fern/gpt-live/overview.mdx

@@ -65,7 +65,7 @@ For you, more of the design lives in the two prompts:
 Vapi connects GPT-Live to your phone numbers and tools, and provides call records and observability according to your recording and data settings:
 
 - Browser, Twilio, Vapi SIP, and WebSocket calls.
-- Function, API request, and MCP tools, plus built-in end-call, transfer, and DTMF tools.
+- Function, API request, and MCP tools, Google Calendar, Google Sheets, and Slack tools, plus built-in end-call, transfer, and DTMF tools.
 - Speaker and reasoner prompts, reasoner skills, personality packs, and 22 voices.
 - Idle-message hooks and HTTP live call control.
 - Transcripts, recordings, structured outputs, scorecards, Boards, Monitoring, and Voice Simulations.
@@ -79,7 +79,7 @@ Before you commit, check whether your assistant depends on something GPT-Live do
 | A squad with handoffs | Not supported. Use one assistant, often with skills |
 | Knowledge bases or the Query tool | Not available. Use a retrieval tool |
 | Warm transfers, or transfers on browser calls | Not supported. Blind transfers work on Twilio and Vapi SIP |
-| Caller keypad input | Not supported |
+| Caller keypad input | Supported on native Twilio and Vapi SIP |
 | Native Telnyx or Vonage numbers | Not supported |
 
 The full list is in [Settings and compatibility](/gpt-live/configuration#compatibility).

fern/gpt-live/testing.mdx

@@ -210,7 +210,7 @@ Set `firstMessageMode` to `assistant-speaks-first` and give a text `firstMessage
 
 ### A voice or tool is rejected when saving
 
-Use `voice.provider: "openai"` with a [supported voice](/gpt-live/configuration#voices), and remove voice and model fallbacks. Use supported tool types with unique names, and check saved tools too. Disable keypad input.
+Use `voice.provider: "openai"` with a [supported voice](/gpt-live/configuration#voices), and remove voice and model fallbacks. Use supported tool types with unique names, and check saved tools too.
 
 ### WebSocket calls fail to start or sound distorted
 

fern/gpt-live/tools.mdx

@@ -139,6 +139,20 @@ MCP tools you already use with a Vapi assistant work with GPT-Live, with their e
 
 At the start of a call, Vapi connects to the MCP server and makes its tools available to the reasoner. The tool list stays fixed for that call, so start a new call to pick up changes on the server. Put tool-use procedures in the reasoner prompt and delegation triggers in the speaker prompt.
 
+## Google Calendar, Google Sheets, and Slack tools
+
+The reasoner can run Vapi's Google Calendar, Google Sheets, and Slack tools: `google.calendar.availability.check`, `google.calendar.event.create`, `google.sheets.row.append`, and `slack.message.send`. They use your organization's connected credential and the same configuration as on a Classic assistant, so the calendar and time zone, or the spreadsheet and range, that you set on the tool become the defaults for each call. GoHighLevel tools are not supported.
+
+Set a `function.name` on each of these tools. Without one, the name defaults to the tool type, whose dots the reasoner rejects, and every delegation on the call fails.
+
+GPT-Live does not apply a tool's `rejectionPlan`. A Google Calendar, Google Sheets, or Slack tool that has rejection conditions is refused when you save, rather than run without its guard, so remove the rejection plan or use a Classic model. Rejection plans on `function` and `apiRequest` tools are ignored.
+
+The reasoner hears the outcome of each call:
+
+- A missing connection, invalid arguments, or an unavailable client is a definite error. The reasoner learns the action cannot run on this call, and the instruction to connect the integration goes to the call logs, not the caller.
+- A failed or empty response to a write, such as an event, a row, or a message, is an unknown outcome, because the write may already have happened. The reasoner is not told it failed and does not retry.
+- A failed availability check is a plain error, since a lookup changes nothing.
+
 ## Check the outcome, not just the conversation
 
 When you test a tool, look at three things together: what the assistant said, the tool calls and results in the call's messages, and your service's own records. The assistant saying a booking is done doesn't prove it happened. [Test and improve](/gpt-live/testing#scenarios-to-run) has a set of scenarios to run, including corrections, failures, and slow tools.

fern/providers/model/deepseek.mdx

@@ -32,6 +32,7 @@ For additional API configuration options, review the [`DeepSeekModel` fields](/a
 
 | Model | Model ID |
 | --- | --- |
+| DeepSeek Flash | `deepseek-flash` |
 | DeepSeek-V3 | `deepseek-chat` |
 | DeepSeek-R1 | `deepseek-reasoner` |