StudyHub 2.7.1

• Top up a published deck. The 资料 row and the reader's outline now offer 「为没覆盖的部分补题」 for a material whose deck is already published but still has sections without questions. It writes a NEW draft for only the uncovered sections, in rounds of at most 30 questions, automatically until covered and pausable, with the estimate 「覆盖现在 5/81 → 本轮后约 43% → 目标 100%」 before it starts. When you publish it, you choose to merge it into that deck as its second part (or make a new deck); the deck page then says 「第一部分 7 题 · 第二部分 109 题」 and can filter by part, while practice, mastery and coverage count the deck as a whole. The published deck is not touched until you confirm.
• A failed or stopped run can be continued. After a time limit, a model failure or a stop, 接着做 is offered on the home banner and row, in the Jobs console and on the draft page, with the reason and the real numbers in front of it (「已出 4/15 题保留，接着补 11 题」). It keeps every approved question and makes only what is still owed. The old record is kept as 「接着做过了」 with a link to the new task instead of disappearing. 「为没覆盖的部分补题」 on a draft now runs as coverage rounds too (automatic until covered, pausable), and a batch that is still being written no longer reads 「覆盖 0/N」.
• The Jobs console states the time limit that stopped a task. 「运行时限 20 分钟 · 已用 20 分 1 秒 · 单次模型调用最长 10 分钟」, what was kept, a 「调整时限」 button that opens 设置 › 出题偏好, and the slowest steps named and marked on the timeline.
• Marker is no longer called "not ready" when it is only slow to start. The check now waits up to two minutes (it used to give up after 20 seconds, but a cold start takes longer), and a timeout says so instead of blaming the program path.
• The "no original file" notice can be closed. It folds into one quiet line 「这份资料没有原文件。 补全原文件…」 that keeps the action.
• The Jobs console shows how fast the model was, not just how much it used. Beside 实际用量 every job now carries DSH's own two speed figures from 会话统计: 首 token 平均（TTFT） — how long the model took to start writing — and 输出速度（TPS） in tok/s — the tokens it wrote per second of writing. They arrive the way tokens do: a question-writing phase is a DSH child session, and StudyHub reads DSH's own sessionStats through the same observation lease it already uses for usage, so what you see is what the harness itself counted; audio-text and translation phases, which call the model directly and are no DSH session, are measured on the same boundaries. A figure nobody could measure is simply not shown (a call still running, a transcription that does not stream, a provider that reported no usage), never estimated, and only settled calls count — so a running job's numbers grow as its calls finish. Same wording and rounding as DSH: 1.6秒 under a minute, 2分42秒 over it, whole tok/s from ten up.
• Fewer tokens for a few questions from a long material. Asking for a small number of questions (10 or fewer, or fewer than a quarter of the sections) no longer reads the whole material first just to rate how important each section is: the questions go to the longest sections either way, so the sections are weighed by length and the plan line says so. In measured runs a 4-question job on a long material used 17–46% fewer tokens (the longer the material, the more it saves). Choosing 精简 / 标准 / 完整 is unchanged.
• Less repeated text in every question run. The list of questions you already have is now sent only to the step that picks the knowledge points (which already avoids repeating them), not again to the answer and writing steps, and the answers step no longer receives your reference questions (the writing step and the review still do). In a measured 20-question run it was about 27,000 tokens (16%) fewer with 400 questions already in the library, about 3% fewer with reference questions, and about 1% with a small library.
• More of what is sent again can be served from the provider's cache. The parts of a request that change (the number of questions, the plan so far) now come after the parts that stay the same, and the plan step is sent only what it needs. A provider that caches repeated starts of a request now reads more of a 20-question run from cache (about 26% before, 40% after in a measured run), which lowers the charge on providers that bill cached tokens less. What a model is asked to do is unchanged.