對話或文件太長，超出模型負荷的情況

簡短回答

Whizi不會顯示情境上限的錯誤訊息。產品中沒有任何字串提到情境視窗或代符上限,因為一段超出模型負荷的對話,會在請求送出前被靜默裁剪以符合上限,而不是被拒絕。系統不會告訴你這件事發生了。如果模型看起來忘記了一段長對話中間的內容,你看到的就是這個情況。

有四種情況會直接拒絕你的訊息,而且各自都會表明自己：

訊息	HTTP代碼	觸發條件
This message is {count} characters, over the 100,000 character limit. Attach a shorter file, or ask about one section at a time.	400 message_too_long	單則訊息(包含從你的檔案中擷取出的文字)超過100,000個字元
This conversation has {count} messages, over the 100 message limit.	400 too_many_messages	單一請求所帶的對話紀錄超過100則訊息
Request is too large.	413 request_too_large	整個JSON請求主體超過路由的位元組上限
That system prompt is missing or over the 32,000 character limit.	400 invalid_system_prompt	系統提示超過32,000個字元

字元上限字串中的{count},會填入你的實際數字,並以千分位分隔符號格式化。每則字串旁的代碼,是網路追蹤紀錄中會顯示的內容,即使介面只顯示那句話。

如果你看到的訊息提到了情境長度或代符數量,那並非來自Whizi。請跳到最後一個段落。

每個模型都有的預算,以及超出之後會發生什麼

目錄中每個模型在單一回合能拿到相同的預算：40,000個輸入代符與20,000個輸出代符。唯一的例外是加拿大CPA代理人,擁有55,000個輸入代符與40,000個輸出代符。

當一段對話超出這個預算時,後端會靜默地把歷史紀錄裁剪到模型的代符預算內,而不是拒絕請求。不會有提示訊息、橫幅通知,也不會有對應的錯誤代碼。

Whizi用來裁剪的代符計數是估算值,而非真正的代符解析器(tokenizer)。它在JSON上可能比真正的代符解析器少算最多1.66倍,因此輸入端套用了1.8倍的餘裕,以涵蓋最壞的實測情況。

換成情境視窗更大的模型,並不會送出更多內容

這是最常見的錯誤解法。40,000代符的輸入預算是固定的：無論是擁有一百萬代符視窗的模型,還是擁有20萬代符視窗的模型,拿到的都一樣。把一段長對話從一個大視窗模型換到另一個大視窗模型,並不會改變送出的內容量。

情境視窗大小只會朝單一方向改變預算,也就是往下調。任何視窗低於93,000代符的模型,拿到的都是較小、按比例計算的預算,輸出上限為視窗的40%,並保留1,000代符的安全餘裕。目錄中有31個模型受到這樣的限制,其中最小的視窗只有6,144代符。

所以真正有幫助的切換,恰好和大家常嘗試的相反：把對話從一個受限的小模型換到一個普通模型上,而不是在兩個大視窗模型之間換來換去,後者對長度完全沒有影響。對話進行到一半換模型時的行為,在對話進行中切換模型裡有說明。

關於93,000這個數字,還有一個值得了解的細節,對於你在思考為什麼一個模型會拒絕一件看似很小的請求時很有幫助：OpenRouter計算模型視窗時,會把輸入加上請求的最大輸出一起算,而不是只算輸入。

過長的上傳檔案會被裁剪,而且系統會告訴你

上傳檔案是單則訊息超過100,000個字元最常見的原因,因為PDF、Word與試算表檔案會在你的瀏覽器中被擷取成文字,而這些文字和你打的字算在同一個上限裡。

當擷取出的文字放不下時,會被裁剪而不是被拒絕,並且會出現兩段字串。提示訊息會顯示Your upload was too large, so only the first part of it was sent. Ask about a smaller section for full coverage.。訊息本身則會在裁切處帶有標記[Attachment truncated: the upload was larger than one message can carry, so the content past this point was not included.],讓模型能看到自己的副本從哪裡開始不完整。

如果訊息是被拒絕而不是被裁剪,你會看到第一個表格中的message_too_long字串。修正方式就是錯誤訊息本身指出的：附上較短的檔案,或一次只問一個段落。

還有一種行為看起來像是遺忘：只有帶有附件的最新一則使用者訊息,其附件才會被轉送給模型。十個回合前附加的圖片或PDF,不會在之後每一回合都重新送出。如果你需要模型再次查看它,就要重新附加一次。Whizi接受哪些檔案格式以及擷取方式如何運作,寫在支援的檔案類型裡。

順帶一提成本方面的事,因為長度會改變一個回合的價值。在Auto模式下,超過約6,000個字元的訊息會被歸類到長篇這一階,收費4點數,理由是這麼長的訊息比較像是貼上的文件,而不是一個問題。簡短的問題則會歸類到快速這一階,收費1點數。點數換算方式寫在點數如何運作裡。

釘選的專案檔案,每一回合都會計入提示內容

釘選的專案檔案,會在那個專案裡的每一回合都以提示文字的形式一起送出,而不是只送一次,這也是為什麼圖片被刻意排除在釘選檔案類型之外的原因。

上限是各自獨立的：每個釘選檔案最多貢獻32,000個字元的擷取文字,整個專案區塊上限為120,000個字元,最多可釘選10個檔案。專案的自訂指示最多可以到32,000個字元。

釘選的檔案與指示,會在那個專案裡的每一回合重新組進提示中,並和對話內容共用同一個輸入預算。如果一個專案對話比一般對話更快跟不上脈絡,試著取消釘選你目前沒有在問的檔案。

如果你確實看到了情境長度錯誤

那麼它來自模型供應商,而不是來自Whizi,並且是透過直通機制傳到你這裡的。任何不是速率限制的上游失敗,都會以HTTP 502搭配代碼provider_error回傳,並附上供應商的訊息,截斷至300個字元。當供應商的錯誤內容完全無法解析時,你會看到的是The model provider rejected the request.。

供應商因長度而拒絕時,一定會提到情境長度與代符數量。這些數字,是供應商用一個比Whizi送出的預算更小的視窗來計算你的請求,而這正是客服需要拿來查看的東西。

沒有任何介面設定能改變這件事。換到另一個模型來得到答案,並把包含數字在內的完整訊息傳給客服。

還有兩段字串常被誤認為長度問題。Generation failed mid-stream.與The model stream was interrupted.是回覆進行到一半的連線失敗,不是長度拒絕,重試即可。Too many requests. Please wait and try again.則是每分鐘10則訊息的速率限制,同樣和長度無關。