feat: 添加 davinci-002 和 babbage-002 模型 - #42
Merged
Conversation
Contributor
Author
|
|
sususu98
pushed a commit
to sususu98/new-api
that referenced
this pull request
Dec 1, 2025
This migration file was a duplicate entry created during PR QuantumNous#42 merge. It was never registered in _journal.json and the fields it added (allow_view_provider_info, non_admin_currency_display) were not included in schema.ts or used in the codebase. The official 0013 migration is 0013_outgoing_justin_hammer.sql which creates the notification_settings table. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
sususu98
pushed a commit
to sususu98/new-api
that referenced
this pull request
Dec 1, 2025
sususu98
pushed a commit
to sususu98/new-api
that referenced
this pull request
Dec 1, 2025
Resolved conflicts: - VERSION: Updated to 0.2.22 - public/seed/litellm-prices.json: Used main's version (more up-to-date) - drizzle/meta/_journal.json: Kept dev's migration 0014 - src/app/v1/_lib/proxy/forwarder.ts: Merged client abort detection with proxy error handling - Removed duplicate migration file 0013_optimal_darkhawk.sql Changes from main: - REST API support and notification system (PR QuantumNous#42) - Updated LiteLLM price data - Version bump to 0.2.22 Changes from dev: - Provider-level proxy support (HTTP/HTTPS/SOCKS4/SOCKS5) - API documentation enhancements - Price table pagination - Migration 0014 for proxy fields All type checks passed ✅ 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
x22x22
pushed a commit
to x22x22/new-api
that referenced
this pull request
Apr 24, 2026
feat: 添加 davinci-002 和 babbage-002 模型
jiutubaba
pushed a commit
to jiutubaba/fx-api
that referenced
this pull request
May 17, 2026
lingozhi
pushed a commit
to lingozhi/new-api
that referenced
this pull request
Jul 17, 2026
Measured over 262 prod requests, all six channels serving the SAME model at the SAME reasoning effort — so the spread is the channel, not the request: #41 1275ms (n=90) QuantumNous#51 1328ms (n=66) QuantumNous#42 2337ms (n=17) #33 3388ms (n=24) QuantumNous#45 3537ms (n=52) QuantumNous#57 8133ms (n=8) Bucketing by uncached prompt tokens holds p50 flat (1612/1934/2073/1802 for 0-2k/2-6k/6-20k/20k+), which rules out prefill volume as the cause. Meanwhile ~100% of requests are affinity-pinned, so the health-weighted selection that was supposed to steer around slow channels almost never runs — the only exit is IsChannelFastEnoughForAffinity, and `score > 0.1` with `score = 1/(1+latency)` only fires past 9s. QuantumNous#45 and QuantumNous#57 kept their sticky traffic forever; 33% of requests were pinned to a channel 2.6x+ slower than the one next to it. Release relative to the best peer for the same model+path instead: leave only when the sticky is BOTH slower than 2s absolute and >2x that peer. The absolute floor stops churn over gaps nobody can feel (0.3s vs 0.15s is 2x), the ratio stops churn for gains too small to repay a migration. QuantumNous#42 at 1.83x stays. The reason this could not just be turned on: migration causes a cold prompt cache by construction, and a cold 240k-token prefill measured 23348ms. That one number breaks two mechanisms at once, both of which then punish the channel we just chose *for being the fastest*: - the latency EWMA, which is shared by every affinity key on the channel, so one migration would make the destination look slow to all of them and stampede them off it, each paying its own cold prefill; - cooldownSlowChannelIfNeeded, an entirely separate path that yanks a channel out of rotation for 30 minutes past 30s FRT — 23.3s is 78% of that. So the release is gated three ways. ColdCacheStart marks the attempt and keeps its latency out of both mechanisms (failures still count — a cold start is no excuse for erroring). A per-key cooldown stops one key bouncing. A global minimum interval drains a slow channel one key at a time, because the slow verdict is per-channel: without it every key pinned to QuantumNous#45 leaves on the same tick and their cold prefills land on #41 together, making it genuinely slow — a cascade no latency-exclusion can prevent, since that load is real. Circuit-open releases stay unconditional and never reach AcquireChannelHealth, or a rate-limited key would be parked on a tripped channel and a paying request would become its half-open probe. Accepted: weighted re-selection can hand a released key back to the same slow channel (~12.5% by weight). Not excluded — that risks a 503, and the cache there is still warm, so the only cost is the 10-minute slot. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
lingozhi
pushed a commit
to lingozhi/new-api
that referenced
this pull request
Jul 18, 2026
…n failure Tracing per-session cache hits in prod exposed the real cause of the slow first tokens. A session's first-token latency tracks one thing: whether this request hit the upstream prompt cache. Cache hit (fresh tokens ~2.6k median) → ~1-2s. Cache miss (fresh ~195k median) → a full 20-40s prefill. 73x apart. The upstream KV cache lives on whichever provider served the prior turn, and affinity exists to keep hitting it. But the slow-channel migration added earlier fought that. When upstreams got busy and a sticky channel's first token crossed the 9s slow bound, its circuit tripped and affinity released the session to another channel — which had no cache for this conversation and paid a full cold prefill. Under load every channel trips in turn, so one session churned QuantumNous#42->#41->#29->#17, a 10-26s cold prefill on every hop, then ran at 1-2s once it finally settled. The migration meant to escape slowness was manufacturing it: leaving a slow-but-warm channel for a cold one is strictly worse, because a cache hit is fast even on a slow channel. So affinity now distinguishes why a channel is unavailable. openWithBackoff records whether the circuit tripped on slowness or on failures. AcquireChannelHealthForAffinity keeps a cache-holding session on a slow-open channel (the cache still makes it fast, and unlike the normal acquire it is not gated by the half-open probe lease) and releases only on failure-open, where staying would just error and the relay retries anyway. Normal selection still avoids slow-open channels, so only the already-warm session stays. This removes the whole slow-migration mechanism it supersedes: ChannelAffinityDecision / ReleaseSlow, the best-peer scan, and the per-key/global release rate limiters (service.TryReleaseChannelAffinity and friends). The fast-channel selection boost stays — it helps a genuinely new or failed-over request pick a fast channel, where there is no cache to lose. ColdCacheStart stays too: leaving a failing channel still lands cold, and that prefill must not poison the new channel. Test rides a session through a slow-open channel (must stay) and a failure-open channel (must leave); it fails if slow-open is treated as unavailable. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
zhibisora
added a commit
to zhibisora/new-api
that referenced
this pull request
Jul 22, 2026
(cherry picked from commit c8cbd5a69b1602aab81bcc7f08d8a90765a6bbb5)
Firesuiry
pushed a commit
to Firesuiry/tako-newapi
that referenced
this pull request
Aug 27, 2026
…tomic-redemption fix(catfk): atomically rebate checkout grants
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
收费截图如下