DeepSeek Harness Session Log Space: Measure Before Scaling

Start with a capacity formula, not a message count

Use this model:

Planned capacity
= online session data
+ persistent attachments
+ workspace artifacts
+ runtime cache
+ migration copies
+ recovery copies
+ free operating reserve

For a recurring workload, expand the first five terms:

Online session data
= measured task delta
× tasks per period
× retention periods
× concurrent active workloads

This formula deliberately separates data that is easy to confuse:

The official architecture describes core/session as the owner of the append-only SessionEvent log. It also states that durable session events include turn, step, user message, assistant, and tool events. The session log is used for context derivation, replay, resume, fork, transcripts, telemetry, and persistence. (github.com)

That architecture creates an important planning rule:

A conversation with few visible messages can still create substantial storage growth if it invokes tools, streams assistant chunks, injects context, or produces large results.

What the event log actually captures

DeepSeek Harness is not documented as a simple transcript file. Its official architecture says that every model-visible input must be reconstructable from the session log, and that raw assistant chunks preserve replay and UI fidelity. The official product page also describes an append-only log containing system prompts, reasoning, tool calls and results, subagent scheduling, and context injections. (github.com)

For measurement, treat these as separate event families:

• user/message
• assistant/*
• tool/call
• tool/result
• turn/*
• step/*
• Approval or permission events
• Context injection events
• Compaction or recovery-related records
• Subagent and job activity

The exact names and serialization format may change because the project remains in developer preview and explicitly warns about compatibility-breaking changes. (github.com)

Do not estimate storage from token consumption. Tokens describe model input and output. Disk usage includes event envelopes, serialized metadata, repeated tool payloads, file references, binary attachments, indexes, and temporary files. DeepSeek API context caching is another separate layer: the API documentation says requests can create disk cache units for common prefixes, but that cache should not automatically be counted as the local DeepSeek Harness session directory. (api-docs.deepseek.com)

A repeatable first measurement looks like this:

# Run before starting the benchmark task
date -u
dsh --profile web --dump-config > /tmp/dsh-config-before.txt

du -sh "$HOME" 2>/dev/null
find "$HOME" -type f -mmin -10 -print0 2>/dev/null \
  | xargs -0 ls -lh 2>/dev/null

After the task finishes, run the same commands:

date -u
dsh --profile web --dump-config > /tmp/dsh-config-after.txt

du -sh "$HOME" 2>/dev/null
find "$HOME" -type f -mmin -10 -print0 2>/dev/null \
  | xargs -0 ls -lh 2>/dev/null

The output is useful only when the benchmark records the exact Harness version, profile, workspace, model mode, task type, and observation window. A directory difference without those labels is not a reusable capacity metric.

Tool output sets the upper bound for long tasks

Tool results often determine the storage ceiling before ordinary chat text becomes important. A build command can return compiler output, a repository search can produce large code excerpts, and a browser or MCP tool can return structured records that are later included in the context.

The main distinction is whether the result is:

1. Serialized into the session event stream.
2. Written as a workspace artifact.
3. Both serialized and written separately.
4. Temporarily cached and later removed.
5. Referenced by path while the underlying file remains in the workspace.

The official turn flow lists tool calls and tool results as durable session events. It also says that the model history is derived from the log, so a result that reaches a model request must be reconstructable from that stream. (github.com)

Use a controlled benchmark rather than assuming that output truncation saves a fixed percentage:

#!/bin/bash
set -eu

ROOT="${1:-.}"
OUT="${2:-/tmp/deepseek-harness-storage}"

mkdir -p "$OUT"

echo "timestamp=$(date -u +%FT%TZ)" | tee "$OUT/measure.txt"
echo "root=$ROOT" | tee -a "$OUT/measure.txt"

du -sk "$ROOT" | tee -a "$OUT/measure.txt"
find "$ROOT" -type f -print0 \
  | xargs -0 stat -f '%z %N' 2>/dev/null \
  | sort -nr \
  | head -50 \
  | tee "$OUT/largest-files.txt"

Run the same task under different output policies, such as:

• Full command output retained.
• Command output summarized by the tool.
• Large generated files kept only in the workspace.
• Search results limited to selected files or ranges.
• Build logs redirected to a separate artifact directory.

The result should be recorded as:

task_id=
harness_version=
profile=
workspace=
output_policy=
duration=
session_delta_bytes=
tool_result_delta_bytes=
workspace_delta_bytes=

Do not publish an alleged “typical saving” unless the same benchmark has been repeated on the same build and workload. A shorter transcript may improve readability without reducing the underlying workspace footprint.

Attachments require file-level accounting

The long tail called “image attachments” is not a count-based problem. Two images can have very different sizes, formats, metadata, and forwarding behavior. A single image may also exist in more than one location:

• Original upload or import directory.
• Session attachment record.
• MCP or ACP forwarding copy.
• PTC-generated intermediate asset.
• Thumbnail or preview cache.
• Restored-session copy.
• Backup or migration archive.

The v0.1.0-rc.7 release notes confirm durable image attachments for MCP and ACP and nested image forwarding in PTC Mode. They do not define a universal storage multiplier, retention rule, or cross-version compatibility guarantee. (github.com)

Measure an attachment task separately:

# Capture files created or modified during the attachment test
find "$HOME" -type f -mmin -20 -print0 2>/dev/null \
  | xargs -0 stat -f '%z %N' 2>/dev/null \
  | sort -nr \
  > /tmp/attachment-files.txt

# Review total size by visible path
awk '{ total += $1 } END { print "bytes=" total }' \
  /tmp/attachment-files.txt

The test should include a fresh session, a resumed session, an MCP or ACP handoff if the production workflow uses one, and a PTC workflow if nested forwarding is enabled. Record whether the restored session can display and reuse the attachment before deleting any copy.

Sensitive images also create a retention obligation. Screenshots may contain credentials, customer data, source code, or personal information. The cheapest cleanup action is not automatically the safest one. Storage planning must state who may delete the attachment, when deletion is allowed, and whether an audit record must remain.

Workspace artifacts are a separate storage budget

A DeepSeek Harness workspace can grow even when the session log remains stable. The official user guide says the process uses its invoking directory as the default filesystem location and requires a selected workspace before a Web UI session can operate. It also states that the Agent can read and edit workspace files, run commands, delegate work, and maintain a plan. (github.com)

Track at least these workspace categories:

• Build output and dependency directories.
• Generated source files and patches.
• Downloaded datasets and archives.
• Search indexes and local databases.
• Screenshots, exports, and reports.
• Temporary files produced by tools.
• Logs created by external commands.
• Package-manager caches.

A useful measurement sequence is:

1. Record the workspace size before the task.
2. Run the exact task from a clean branch or fixture.
3. Record the session directory size.
4. Record the workspace size.
5. List the largest new files.
6. Repeat after resume.
7. Delete only the files covered by the retention policy.
8. Run the task again to verify that cleanup did not break recovery.

This matters for cloud Mac planning because a machine can have enough room for the session database but fail during a build, dependency install, or artifact export. The relevant Mac storage figure is the sum of both workloads, not the session directory alone.

Backups and recovery copies need their own reserve

Backups should not be counted as usable work space. Separate these terms:

Online working set
= session events + attachments + workspace + active cache

Recovery reserve
= migration copy + backup copy + rollback copy + restore staging area

On APFS, snapshots are read-only copies associated with a volume, and Apple Disk Utility exposes metadata such as private size and cumulative size. That means a snapshot must be inspected rather than treated as a zero-cost safety feature. (support.apple.com)

Use these commands where supported:

diskutil apfs list
tmutil listlocalsnapshots /
df -h /

Then compare:

free_before_restore_test
free_after_backup_creation
free_after_restore_staging
free_after_cleanup

A backup that can be read but cannot resume a session on the current release is not a completed recovery plan. The project is still in developer preview, and the official repository warns that compatibility-breaking changes will occur. (github.com)

Run one restore validation after every change to the Harness package, session format, attachment strategy, or compaction behavior. Record:

source_version=
backup_created_at=
restore_version=
session_opened=
history_replayed=
attachment_visible=
workspace_consistent=
task_resumed=

If any field fails, keep the backup and stop automated cleanup until the failure is understood.

Apply the decision conditions before scaling

Use these branches after measuring a representative task:

• If session-event growth is low but workspace growth is high, keep the session retention policy and move build outputs, indexes, and generated artifacts to a separately managed volume or artifact store.
• If tool-result growth dominates, reduce unbounded command output, cap search scope, and retain full results only for tasks requiring audit replay.
• If attachments dominate, define an image retention class, deduplicate forwarding copies where supported, and verify restored-session behavior before removing originals.
• If backups consume the reserve, reduce the number of online copies only after a successful restore test; otherwise select a larger cloud Mac storage allocation.
• If no safe cleanup rule exists, expand first and investigate second. Deleting unknown session data is an operational risk, not a capacity strategy.
• If the workload is stable and long-running, compare the total lease cost of a larger persistent Mac with repeated migrations, failed restores, and manual cleanup.
• If the workload is experimental or short-lived, a smaller temporary environment can be reasonable, provided the measured task delta and recovery copy fit within the lease window.

For planning, use:

Required storage
= baseline Mac usage
+ (task delta × task frequency × retention)
+ workspace growth
+ attachment growth
+ backup copies
+ restore staging
+ reserve

Fill every term from measurements. If a term is unknown, label it unknown rather than replacing it with a confident fixed number.

FAQ: storage paths, long sessions, and cleanup

The following answers address the operational questions that usually appear during procurement and rollout.

Where does DeepSeek Harness keep session logs?

Do not hard-code a path from another project or an older build. The official architecture identifies core/session as the owner of the append-only SessionEvent log, while the user guide identifies the invoking directory as the default filesystem location. Inspect the active profile, workspace, and application data directories on the exact release being deployed.

How much space can a long session consume?

There is no safe universal estimate. A long session may include assistant chunks, tool calls, command output, approvals, context injections, attachments, and workspace files. Measure the directory before and after a representative task, then multiply the observed delta by task frequency, retention, concurrency, and the number of recovery copies.

Are image attachments persisted?

The official v0.1.0-rc.7 release notes confirm durable image attachments for MCP and ACP, plus nested image forwarding in PTC Mode. The release note confirms capability, not a fixed byte cost. Read the actual file sizes and repeat the test after resume, migration, and backup restoration.

How much log space should a cloud Mac reserve?

Use a measured working set plus a separately measured recovery reserve. Do not count backup-only capacity as available workspace. If the Mac will host several independent projects, calculate each project’s task delta and retention policy before adding concurrency. A temporary environment may need less retention than a long-term audit environment.

What can be cleaned safely?

Start with reproducible workspace artifacts, expired exports, and caches covered by policy. Treat session events, attachments, and recovery copies as protected until the current release has passed a restore test. Never remove an active session directory merely because its files look old; age alone does not prove that the data is disposable.

Turn the measurement into a cloud Mac decision

After the benchmark, record one line for each workload:

workload=
harness_version=
task_delta_bytes=
workspace_delta_bytes=
attachment_delta_bytes=
tasks_per_week=
retention_weeks=
concurrent_tasks=
backup_copies=
restore_staging_bytes=
required_reserve_bytes=
planned_storage_bytes=

The result should drive the lease, not the other way around. NodeMini’s cloud Mac options can be compared only after the measured session, workspace, and recovery requirements are known. For regional delivery planning, the Hong Kong cloud Mac option and Silicon Valley cloud Mac option provide starting points, but neither location removes the need to measure storage growth.

A self-managed Windows or Linux host may appear cheaper, but it can introduce extra work around macOS-specific validation, remote access setup, filesystem permissions, backup tooling, and environment drift. A local Mac avoids remote latency but ties capacity to hardware already owned and may be difficult to resize during a short test. Renting a Mac through NodeMini is more attractive when the requirement is a temporary DeepSeek Harness evaluation, a controlled migration window, or a measured workload that needs flexible access without an immediate hardware purchase. The correct choice still depends on the measured formula and whether the workload needs long-term persistent storage, physical peripherals, or uninterrupted ownership.

Before expanding storage this week, run one clean benchmark, one attachment test, and one restore test. If the resulting numbers are still uncertain, keep the uncertainty visible and choose a fallback expansion path instead of inventing a fixed configuration.