Skip to content
MyDSHMy DSH Field Notes
中文
Independently maintained; not affiliated with DeepSeek. No association with mydsh.dev or other MyDSH sites.

Home/Modes & context/PTC vs standard

Batched repetition versus small tasks: where PTC diverges

Trying to classify your task as batched repetition or a small job, and what that implies for preset choice.

To be testedVersion and environmentChecked 2026-11-14
Source
official description plus structural reasoning; the paired run is not done
Checked
2026-11-14
Honest note: no paired measurements yet. What follows is an executable experiment design plus expectations derived from structure, not results. The numbers go in once both groups have three runs each.

Why the two shapes diverge follows from structure:

Task shapenativeptcExpected
Batched repetition (one action across 50 files)50 tool calls, 50 full round tripsOne loop, one run_code, one round tripPTC clearly cheaper
Small job (read 2 files, summarise)2 calls, 2 round tripsStill generates the SDK prompt, then a program: saves one round trip, pays a fixed prompt costRoughly break-even, maybe slightly worse
Each step depends on the previous resultThe model inspects each result before decidingBranches must be written in advance; judgment thins outPTC not worth it
Independent, parallelisable operationsSerial callsThe program can overlap them (maxParallelSubCalls, default 10)PTC may be faster

Designing the experiment

  1. Batch group: 50 structurally identical files, one action (take the first 100 characters of each). Three native runs, three PTC runs.
  2. Small group: two files, one summary. Three runs each.
  3. Record only: tool calls, round trips, input/output tokens, whether the output is byte-identical.
  4. Log time but do not make it the lead metric — network variance swamps the signal.
# batch group (50 files)
Read all 50 markdown files under files/, take the first 100 characters of each, and compile table.md

# small group (2 files)
Read a.md and b.md and merge them into summary.md

One variable people miss

PTC has a maxParallelSubCalls setting, default 10, capping concurrent sub-calls within one run_code program. The comments say it follows native's scheduling contract: only tools classified as concurrency-safe overlap, exclusive calls act as barriers, and setting it to 1 restores strict serial dispatch.

So the comparison is not 'one mode versus another' but 'one mode versus a mode with a tunable knob'. Any write-up must state the maxParallelSubCalls value, or the numbers cannot be reproduced.

What counts as working

Check every line. All of them pass or the job is not done.

  • Three runs per group
  • The maxParallelSubCalls value is recorded
  • Outputs are byte-identical, or it is not the same task

Where it fails

Symptom, cause, what to do — written in the order it actually happens.

SymptomCauseWhat to do
Outputs differ between groupsAmbiguous instruction, two interpretationsFix the output format and rerun
Huge time gap with identical round tripsNetwork or server varianceUse round trips as the primary metric

Sources

Verified means measured here. Compiled means every line carries a source.