Uncensored LLM API benchmarks: DeepSeek V4.1 Flash

RedRouter benchmarks uncensored model APIs every 8 hours from US East and US West. In the 72 hours ending 10 November 2026 at 18:40 UTC, our DeepSeek V4.1 Flash had the highest output speed and the shortest time to 500 tokens of every DeepSeek V4.1 Flash route that completed all of its requests.

DeepSeek V4.1 Flash 1017

RedRouter tests 6 routes to the dated 1017 checkpoint. 3 of them completed all 72 requests: ours, Venice and OpenRouter.

Against Venice, the other uncensored route that completed every request, we streamed 16% faster (216 against 186 tokens per second) and reached 500 tokens in 3.0 seconds against 3.2. Venice returned the first token sooner, at 0.5 seconds against our 0.6.

Heabsy had the highest speed at 371 tokens per second and completed 16 of 72 requests, with 32 server errors and 24 client errors. OrcaRouter completed 32 of 72. RedRouter marks both as failing. OpenRouter serves the unmodified model.

The 2 regions were close. We streamed 216 tokens per second from both US East and US West, with the first token at 0.7 and 0.5 seconds. At the 90th percentile, our first token took 1.6 seconds and 500 tokens took 7.5. Venice's figures were 0.9 and 7.4.

Our blended price was $0.394, 32% below Venice's $0.578. OpenRouter and Sable were cheaper.

The undated DeepSeek V4.1 Flash routes

RedRouter lists 5 more routes on a separate board as an undated DeepSeek V4.1 Flash derivative. It keeps undated aliases apart from the dated checkpoint because it can't confirm which checkpoint they serve. None of the routes there that completed every request matched our 216 tokens per second.

How RedRouter measures

Everything below comes from RedRouter's methodology, version 1.0.0, in effect since 5 November 2026.

What a route is

A route is a gateway, a model, a modification and, where the gateway allows it, a pinned supplier. RedRouter pins suppliers and turns off fallback wherever a gateway supports that. Modification, precision and context window are what each provider declares. RedRouter doesn't verify them.

The workload

Each run sends every route 4 requests from each region: about 1,000 and 8,000 input tokens, each with a prose prompt and a code prompt. The prose prompt asks for a 1,600-word handbook and the code prompt for a complete 200-line module, so both run past the 512-token output cap. Every request starts with a fresh random nonce to reduce cache reuse, uses temperature 0.5 and streams its output. Reasoning is turned off where the provider documents a way to do it.

The schedule

Runs start at 02:00, 10:00 and 18:00 UTC every day, from client machines in us-east-1 (N. Virginia) and us-west-2 (Oregon). Requests to a provider go out one at a time, in shuffled order, each after a random delay of up to 2 seconds. Over 72 hours that adds up to 72 requests per route.

Failures

There are no retries, warm-up calls or replacement samples. A request fails if it runs past 180 seconds, if its first bytes take more than 60 seconds or if the stream stalls for 60 seconds. It succeeds only with a 2xx streamed response, at least 1 piece of content and a normal finish. Every failure counts against the success rate, whatever caused it.

The metrics

• Time to first token: from sending the request to receiving the first piece of content.
• Output speed: the tokens after the first chunk, divided by the time between the first and last pieces of content. Token counts come from the provider's own usage report.
• Time to 500 tokens: time to first token plus the time to stream 500 tokens at that request's output speed. RedRouter calculates it for each request, then takes the median.
• Success rate: successful requests divided by every request attempted.
• Blended price: (3 × input + output) ÷ 4 per 1M tokens, from each provider's declared price, without cache discounts. These are catalogue prices, so fees and promotions can make a bill differ.

The statistics

Results cover a trailing 72 hours. The board shows medians, and the CSV adds the 90th percentile. A metric appears only once a route has at least 8 successful requests, and no outliers are removed. A route is OK at 95% success or better with a success in the last 16 hours, degraded from 80% to 95%, and failing below 80%.

Accounts

RedRouter uses ordinary paid accounts on public endpoints. It takes no provider-supplied keys, priority access, reserved capacity or free tiers.

What it doesn't measure

The suite doesn't measure answer quality, refusal rate, tool-call quality, actual quantization, throughput under heavy load, long-context limits or uptime. RedRouter says 4 requests every 8 hours can't certify an SLA.

The data

The harness is open source under Apache-2.0 and the results are licensed CC BY 4.0. The summary CSV is public, and providers can file corrections as GitHub issues. The board refreshes every 8 hours, so these numbers will move.

DeepSeek V4.1 Flash is on our uncensored models page, with live prices and a sample request.