---
title: 'In the News: August 14, 2026'
description: "DeepSeek repriced its V4 API for August 16 and every off-peak rate still lands above today's price, with cache reads rising hardest."
canonical_url: 'https://darkfactory.dev/news/2026-08-14-morning'
markdown_url: 'https://darkfactory.dev/news/2026-08-14-morning.md'
collection: news
date_published: '2026-08-14T10:30:00-04:00'
date_modified: '2026-08-14T10:30:00-04:00'
---

# In the News: August 14, 2026


DeepSeek's new API prices take effect on August 16, and the cheapest new tier is still more expensive than what you pay today. Two pieces published the same day sit close to that: Earendil on what compaction costs you in prompt cache, and Cursor on pre-warmed cloud environments that go on by default next week. One short argument closes the edition, on why a model that scores better can be worse to work with.

## 1. DeepSeek's new API prices land August 16, and off-peak is not a way back to today's rates

**[DeepSeek-V4-Pro GA Release](https://api-docs.deepseek.com/news/news260813)** · DeepSeek · API documentation, August 13, 2026

DeepSeek promoted V4-Pro to general availability and, in the same post, announced that API billing moves to peak and off-peak rates at 16:00 UTC on August 16. Off-peak is exactly half of peak. Peak hours are 01:00 to 04:00 and 06:00 to 10:00 UTC, and everything else is off-peak. The company's stated reason, from its own changelog, is "to allocate resources more reasonably."

The figures are published on DeepSeek's pricing page. For `deepseek-v4-pro`, output per million tokens goes from $0.87 today to $1.98 off-peak and $3.96 at peak. Cache-hit input goes from $0.003625 to $0.022 off-peak and $0.044 at peak, which is 6.1x and 12.1x. For `deepseek-v4-flash`, output goes from $0.28 to $0.66 and $1.32; cache-hit input goes from $0.0028 to $0.007 and $0.014. Every single rate in the new off-peak column sits above the rate in force today.

**Why it matters:** Agent loops are cache-hit heavy by construction. A long, stable prefix of system prompt, tool schemas and conversation history gets re-sent every turn, and that is the line item rising fastest here, up to 12.1x on V4-Pro. Anyone whose factory economics assumed DeepSeek as the cheap backend has two days to redo the arithmetic, and moving work into off-peak hours does not undo the increase. It halves it.

## 2. Compaction breaks your prompt cache, and Earendil says so in the mechanism

**[How Compaction Works in Pi](https://earendil.com/posts/compaction-in-pi/)** · Earendil Engineering · earendil.com, August 13, 2026

A first-party account of when the Pi coding agent compacts and what it sends when it does. Pi checks for auto-compaction after a turn ends, against a configurable token budget whose current default is 20 thousand tokens, "roughly 5 to 20 turns." It may also compact mid-turn if it hits a context overflow error. Compaction runs as a standalone request that carries none of the existing history, with its own system prompt telling the model "you are a context summarization assistant" and a user message asking for "a structured summary of this conversation branch for context when returning later," with sections for goal, progress and key decisions. Because the request is standalone, it can be routed to a different, cheaper model. The post links the exact prompt construction at pinned line ranges in the Pi repository, so the claims about what Pi sends can be checked against the source.

On caching, the post states: "This caching requires an exact prefix match, so compacting a session will break the prompt cache." The retained turns hold the same tokens, but they now follow a different prefix, so everything after the first changed token has to be recomputed.

**Why it matters:** Compaction is usually argued about as a quality problem, meaning what the summary loses. This puts a price on it instead, and locates the price precisely: not the size of the edit, but the size of everything behind it. Combined with item 1, a badly timed compaction is about to cost more than it did last week.

## 3. Cursor turns pre-built cloud environments on by default on August 17

**[Cloud agents start 3x faster with builds](https://cursor.com/blog/builds)** · Cursor Team · Cursor blog, August 13, 2026

Cursor now prepares "ready-to-use copies of your development environment" in the background, by default once an hour, so a cloud agent forks a warm machine instead of booting, cloning repositories and running the install script at session start. Cursor reports that its own internal environments "boot 10x faster and time to first token is 3x faster." Neither figure comes with a baseline or a stated methodology. Blair McAlpine, senior engineer at Faire, is quoted saying the team kicks off "more than 2,000 automated agent runs a week without any manual prompting" and that broken builds "never take down the agent fleet," because agents keep starting from the last successful build while a broken one is debugged separately.

**Why it matters:** The default flips on August 17 for new and existing environments, and the migration is not a no-op. Builds work by filesystem snapshot, so work that can be done ahead belongs in the install command, credentials for private registries have to move to team or environment secrets because user secrets are deliberately kept out of builds, and the start command still runs per session for anything that must be fresh. If you run Cursor cloud agents, that is a config review with a date on it.

## 4. An argument that benchmark pressure is why agents stopped asking questions

**[Why does Opus 5 feel worse to work with?](https://mun-logadan.github.io/why-does-opus-5-feel-worse/)** · Mun Logadan · personal blog, August 14, 2026

A short post, roughly 450 words, holding that Opus 5 is the more capable model on benchmarks and the worse one to work with, because Opus 4.7, Opus 4.8 and Fable "stop and ask questions if my intent was unclear" and "don't reinterpret or update my plans without asking." The proposed cause sits under a heading the author himself titled "Baseless speculation," and the label is his: "Selecting for models that do well on benchmarks (and indeed training for them or on RLVR tasks in general) inherently selects for models that make bold, usually-correct assumptions in the face of ambiguity. It penalizes models with a tendency to stop and ask for clarification or direction." No measurements are offered, and none are claimed.

**Why it matters:** The claim is unmeasured, so treat it as an argument rather than a finding to cite. It locates the cause of a harness problem in the evaluation arena, outside the model and harness. An agent that never stops to ask is exactly what lights-out operation requires and exactly what the author says he does not want. In his words, "Real life just isn't a benchmark."