Running DeepSeek Harness on an 8GB GPU: Context Tuning, Presets, and Hardware Limits

Part 3 of the DeepSeek Harness: Kernel to Edge series: A hands-on benchmark pairing DeepSeek Harness, Ollama, and Ornith-1.5 on an 8GB RTX 4070 laptop to solve the tradeoff between tool bloat and context headroom.

---

DeepSeek Harness: Kernel to Edge

This article is Part 3 of a three-part architectural and practical deep dive:

1. Part 1: Understanding Cordis: The TypeScript Framework Built for Hot-Swapping Everything (Microkernel primitives, spatiotemporal composability, reverse cleanup stacks, zero-leak lifecycles).
2. Part 2: DeepSeek Harness: How DeepSeek Uses Cordis to Redefine Autonomous AI Agents (The meta-harness paradigm, Cordis as an agent kernel, comparing DSH to OpenCode and Pi).
3. Part 3 (This Article): Running DeepSeek Harness on an 8GB GPU: Context Tuning, Presets, and Hardware Limits (Hands-on local deployment with Ollama, Ornith-1.5, VRAM arithmetic, minimal vs. standard presets, and TUI).

---

1. Introduction: Bringing the Harness Home

In Part 1, we explored Cordis, the TypeScript framework designed for zero-leak dynamic lifecycles and spatiotemporal composability. In Part 2, we mapped the systems architecture of DeepSeek Harness (DSH), showing how it abandons monolithic Python agent loops in favor of a pure plugin microkernel.

Now, we move from architectural theory to a practical, working developer setup.

My target machine is a standard laptop equipped with an NVIDIA RTX 4070 GPU (8GB VRAM) and 32GB of system RAM.

Running autonomous coding agents locally on consumer hardware presents strict physical constraints. Frontier cloud models (like Claude 3.7 Sonnet or DeepSeek-V3) make multi-turn tool calling seem straightforward due to their massive context windows and vast parameter counts. When running an agent framework on an 8GB GPU, you immediately encounter hard physical boundaries:

• VRAM exhaustion: Loading a model and its KV cache can easily exceed 8GB, causing CUDA out-of-memory errors or offloading layers to the CPU, which slows execution to a crawl.
• Context window starvation: Agent frameworks typically inject extensive tool definitions, system instructions, and file trees into the prompt. A default local context window fills up before the agent can complete its first multi-turn refactor.
• Tool-calling fragility: Smaller quantized models often hallucinate parameters or break JSON schemas when overloaded with too many simultaneous tools.

In this tutorial, we will configure a local coding agent on this 8GB machine using DeepSeek Harness, Ollama, and Ornith-1.5. We will explore why DSH's plugin design adapts well to local execution, how to tune the context window, and how agent presets help manage memory bottlenecks.

---

2. Why Choose DeepSeek Harness for a Local Agent?

Most developers look at coding harnesses like OpenCode or Pi when building personal workflows. As we established in Part 2, those are turnkey developer tools designed around fixed, opinionated toolsets.

When your hardware is constrained to 8GB of VRAM, opinionated harnesses can become restrictive. If a harness hardcodes ten developer tools into every single turn, your local model has to parse ten complex JSON schemas on every inference call. That consumes hundreds of tokens of precious context and increases the cognitive load on a smaller model.

This is where DeepSeek Harness's architecture as a meta-harness becomes practical:

1. Native Extensibility and Granular Tool Control: Because DSH has no privileged core, tools and interfaces are not baked into the runtime. Even the Web UI itself is just a plugin: developers who prefer keyboard-driven terminal workflows can easily swap it for community TUIs like dsh-TUI. Across community directories like deepseekplugin.com and dsh-plugins.org, thousands of plugins exist for vision, generative UI, and memory. But when constrained by 8GB of VRAM, this extensibility works in reverse: instead of piling on plugins, you can mount only the exact tools your local model needs (such as file editing and bash) while leaving out all memory-heavy peripherals.
2. Predictable Teardown via Cordis Fibers: Local development involves running code, launching compilers, and watching files. Cordis ensures that every child process or execution sandbox is cleanly terminated when a task completes, preventing zombie processes from stealing system RAM.
3. Declarative Agent Presets: DSH supports configurable agent presets (settings.yaml). Switching from a full development dashboard to a lightweight minimal mode requires only a single configuration line.

Every token saved in the system prompt directly translates to more room for code and conversation history.

Defining the Use Case: An Autonomous Task Worker, Not an Interactive Chatbot

Hardware constraints depend heavily on the intended workload.

Local models are frequently judged as interactive chat assistants (like ChatGPT) or inline autocomplete engines (like GitHub Copilot), where fast token streaming (40 to 60+ tokens per second) is required to maintain user momentum.

DeepSeek Harness serves a different workload: autonomous, multi-turn task execution.

A typical task involves handing off an end-to-end debugging session in an existing repository:

"There is an edge case in the WebSocket session manager where dropped connections leave stale socket descriptors open. Locate the relevant files, write a script to reproduce the leak, fix the cleanup logic, and confirm that the test suite passes."

In this setup:

• Long-running execution: The agent runs across 10 to 30 continuous turns: inspecting directory trees, reading source files, running test scripts in bash, analyzing error traces, applying patches, and re-running the test suite.
• Throughput vs. Resilience: On consumer hardware, a 9B model generating 10 to 20 tokens per second is impractical for live conversation, but completely sufficient for an asynchronous worker running unattended in the background or in a terminal (dsh-TUI).
• The primary constraints: The operational bottleneck is not token generation latency, but lifecycle stability (ensuring spawned compiler processes and file watchers do not leak system resources) and context headroom (preventing prompt overhead from pushing VRAM into system memory).

---

3. Step 1: Installation and Baseline Test with OpenRouter

Before troubleshooting local quantization or GPU memory allocation, we validate that DeepSeek Harness operates correctly on our system using a known cloud endpoint. Building outside-in ensures that any subsequent issues stem from local model configurations, not the harness itself.

Installation

DeepSeek Harness is packaged as an npm module. You can run it directly using npx or install it globally:

# Global installation via npm
npm install -g @deepseek-ai/dsh

Baseline Cloud Configuration

For our initial baseline test, we will connect DSH to OpenRouter, giving us access to frontier models (such as DeepSeek-V3 or Mistral) to confirm tool calling and web console connectivity.

Export your API key in your terminal:

# Windows PowerShell
$env:OPENROUTER_API_KEY = "sk-or-v1-your-key-here"

# Linux / macOS
export OPENROUTER_API_KEY="sk-or-v1-your-key-here"

Launch the web interface:

dsh web

C:\Local\Dev\dsh>dsh web
dsh web: http://127.0.0.1:3080/?token=4n7i06dEtYEUzwuPfVmXVRGEx-fxFRRgoQJx4Yfq3wg
dsh web: opening the default browser; pass --no-open to disable

By default, DSH starts its local web server at http://localhost:3080. Open your browser and navigate to the Coding Agent.

Verify the baseline by sending simple instructions, such as inspecting the current directory or reading the contents of a file.

Watch the console stream the model's reasoning, dispatch the filesystem tool, and return the results. Once you confirm this loop completes without errors, you know the harness, process permissions, and session streams are healthy.

The screenshot below shows the DSH web interface connected to Mistral Small via OpenRouter, displaying initial latency and context metrics.

The Trajectory view breaks down individual execution turns, separating model thinking blocks from raw tool payloads.

Notice in the navigation bar that DSH initialized in Standard mode; we will explore how presets shape agent behavior in Step 3.

---

4. Step 2: Selecting and Preparing the Local Model (Ornith-1.5)

Now we replace the cloud API with a fully local open-weight model.

Why Ornith-1.5?

Model selection on an 8GB GPU balances two requirements: reasoning capacity for multi-file code analysis and physical memory headroom.

1. What is Ornith-1.5? (A Specialized Qwen Fine-Tune)

Ornith-1.5 (9B) is an open-weight model derived from the Qwen2.5 architecture.

While Qwen2.5 provides a strong baseline for code syntax and logic, general instruction-tuned checkpoints often struggle with structured tool calling in autonomous harnesses:

• Schema errors: Base models frequently omit mandatory JSON keys, invent unsupported parameters, or fail to escape control characters in code strings.
• Conversational leakage: Conversational models often prepend tool calls with conversational filler ("Sure, I will execute this command for you..."), which breaks strict JSON schema parsers.
• Context degradation: During extended multi-turn sessions, general models can lose track of earlier tool outputs or swap arguments between different tool interfaces (such as passing bash flags into file editing parameters).

Ornith-1.5 addresses this through fine-tuning on structured agent traces and explicit function-calling datasets. It acts as a tool execution engine: given a tool schema, it generates valid, compact JSON calls on the first attempt and processes output streams directly.

2. Why 9B Parameters on an 8GB GPU?

On an 8GB GPU, parameter count determines whether execution remains hardware-accelerated:

• 7B Models: Fast and lightweight, but often struggle with the multi-step deductive reasoning needed to navigate complex repository structures unattended.
• 14B Models: At 4-bit quantization, 14B weights require ~9GB, immediately spilling across the PCIe bus into system RAM and dropping throughput to 1 to 2 tokens per second.
• The 9B Sweet Spot: At 4-bit quantization (Q4_K_M), Ornith-1.5 occupies approximately 5.5GB of VRAM. This leaves roughly 2.5GB of headroom on an 8GB card, providing the space needed for an extended KV cache and display buffers without triggering CPU paging.

Inference Server: Ollama

We will use Ollama to serve the model locally. Ollama provides a native OpenAI-compatible endpoint (http://127.0.0.1:11434/v1), making integration straightforward.

The 2048 Context Constraint

By default, Ollama initializes models with a 2,048 token context window (num_ctx 2048). While sufficient for simple chat queries, an autonomous coding agent quickly exhausts this budget:

• System instructions and agent personas consume ~400 tokens.
• Tool schemas (filesystem, bash, code editor) consume ~800 to 1,200 tokens.
• Workspace context (directory trees, project files) easily consumes another 500+ tokens.

Under default settings, tool schemas and prompts consume most of the available window before the model even generates its first turn. As soon as a multi-file task begins, the engine either truncates earlier messages or drops tool definitions from context.

Tuning the Context Window to 16K

To give our agent room to work, we need to create a customized model variant with a 16K context window (16384 tokens).

We extract the base model's Modelfile, append the num_ctx parameter, and build a local derivative:

ollama show --modelfile ornith-1.5:9b > Modelfile
echo PARAMETER num_ctx 16384 >> Modelfile

ollama create ornith-1.5:ctx -f Modelfile

This sequence extracts the base template, sets the KV cache allocation parameter to 16,384 tokens, and compiles the new model tag in Ollama.

The VRAM Arithmetic

Evaluating memory requirements for a 16K context window on an 8GB GPU:

The model and its extended context window fit entirely within GPU VRAM. Zero layers are offloaded to CPU system memory, ensuring maximum generation speed.

---

5. Step 3: Trials, Failures, and the Minimal Preset

Connecting our newly created ornith-1.5:ctx model to DeepSeek Harness is straightforward, but our initial run revealed an instructive failure mode.

To understand what went wrong, we first need to clarify how DeepSeek Harness structures its runtime across three distinct layers: Plugins, Profiles & Settings, and Agent Presets.

Untangling the Hierarchy: Plugins, Profiles, and Presets

Developers often use these terms interchangeably, but in DSH they represent a clear three-tier architecture:

1. Plugins (The Capabilities): Atomic modules in the Cordis ecosystem (such as @deepseek-ai/dsh-tool-filesystem or llm-pi-ai, which adapts the provider engine from the open-source pi project). Each plugin provides a specific service, model adapter, tool schema, or execution sandbox.
2. Profiles & Settings (The Application Runtime):
   • Profiles: Application runners (such as dsh web, headless, or sdk) located under $DSH_HOME/profiles/<name>. They define which ordered bundle of plugins Cordis boots into memory for a specific user interface or execution target.
   • User Settings (settings.yaml): The global configuration file located at $DSH_HOME/settings.yaml (or project root). It hot-reloads at runtime without restarting the server, configuring provider credentials, API endpoints, model mappings, and default options.
3. Agent Presets (The Operational Modes): The per-session runtime configurations stored in agent-presets/<id>/agent.cordis.yml and toggled directly in the UI as "Standard mode" or "Minimal mode".

Because of this separation, optimizing DSH for local hardware does not require uninstalling packages or restarting the daemon. While profiles and plugins establish what the server application can do, agent presets dynamically select which tool schemas, system prompt instructions, and context compaction rules are active for the LLM during an execution turn.

The Built-in Presets: Four Flavors of DSH

DeepSeek Harness ships with four distinct built-in agent presets out of the box, each tailored to different operational requirements:

1. Standard Mode (The Full Coding Suite): The default preset for comprehensive repository work. It equips the agent with the complete toolset: file editing, persistent bash shell access, repository and web search, planning, skills (via filesystem discovery and the catalog loader), goals, workflows, and subagent orchestration. External MCP servers are not mounted here by default.
2. PTC Mode (Programmatic Tool Calling): Standard mode augmented with the Code Mode SDK. It retains all Standard capabilities (including skills), while letting the model write and execute an entire TypeScript program to combine multi-step operations in a single pass.
3. Minimal Mode (The Lean Two-Tool Composition): A stripped-down preset providing only two fundamental tools: persistent bash and str_replace_editor. It explicitly excludes skills and cannot mount MCP servers, drastically reducing prompt bloat and simplifying schema constraints.
4. Creator Mode (The Meta-Preset): A specialized preset for inspecting, experimenting with, and authoring custom agent presets. It includes the Standard toolset (including skills) alongside runtime introspection utilities to help developers draft new custom presets (such as connecting external MCP servers via @deepseek-ai/dsh-mcp-client).

Note: Preset Session Semantics & Custom MCP Presets

Preset selections in DSH apply on a per-session basis. When you change a preset in the Web UI, it takes effect on the next session you start; active sessions keep the preset configuration they were initialized with. While external MCP servers are not enabled by default in any of the four built-in presets, you can duplicate any preset into a custom configuration (agent-presets/<id>/) or use Creator mode to mount @deepseek-ai/dsh-mcp-client connections.

The 8GB Dilemma: Why Standard Mode Threatens Local Context

In Section 3, our baseline test with Mistral Small booted in DSH's default "Standard mode".

For frontier cloud models with large context windows (128K+), Standard mode is ideal. It presents the model with a comprehensive developer environment:

• Multi-file patch tools
• Interactive terminal runners
• Web search clients
• Diagnostic loggers and telemetry hooks
• Subagent delegation and workflow engines

However, when targeting a local 9B model (ornith-1.5:ctx) constrained to an 8GB GPU, Standard mode introduces immediate friction:

• Prompt Bloat: Tool definitions consume roughly ~6.9K tokens of context before the user even submits a prompt.
• Cognitive & Schema Load: A 9B model must continuously hold dozens of complex JSON schemas in memory, increasing the likelihood of hallucinated arguments.
• Context Starvation: When tool schemas consume over 40% of our 16K context window upfront, multi-turn reasoning rapidly saturates the remaining headroom and triggers frequent compactions.

The Initial Hypothesis: Configuring "Minimal Mode"

To protect our limited context window, our initial design hypothesis is to test DSH's leanest built-in option: Minimal mode.

Instead of modifying code or uninstalling plugins, we can instruct DSH to activate Minimal mode:

• Masks out telemetry, web scrapers, subagents, workflows, and complex patch tools.
• Retains only core primitives: file modification via targeted string replacement (str_replace_editor) and persistent shell execution.
• Slashes tool schema overhead from ~6.9K tokens down to only ~971 tokens.

On paper, the tradeoff is clear: we exchange peripheral tools to maximize reasoning headroom and generation throughput.

Standard Mode vs. Minimal Mode: The 8GB Tradeoff

Dimension	Standard Mode	Minimal Mode
Primary Target	Frontier cloud models (DeepSeek-V3, Claude)	Local quantized models (7B to 9B on 8GB GPU)
Active Tool Surface	Full suite (Read, Edit, Write, Shell, Search, Subagents)	Two-tool composition (persistent bash, str_replace_editor)
Tool Schema Footprint	~6.9K tokens (~43% of 16K window)	~971 tokens (<6% of 16K window)
Available Context (16K)	~7K to 8K tokens remaining	~15K tokens (>93% available)
Measured Throughput	~12 tokens/sec (TTFT ~3.9s)	~17 tokens/sec (TTFT ~1.5s)
Observed Task Behavior	Capable of deep reasoning, but heavy context churn	Lean schemas, but rigid editing on file creation

While presets can be toggled per session in the web interface, we declare Minimal mode as the default in settings.yaml to test our lean-context hypothesis.

---

6. Step 4: The Complete DeepSeek Harness Configuration (settings.yaml)

All of these requirements are codified into DeepSeek Harness's primary configuration file: settings.yaml.

Place this configuration file in your DSH configuration directory (typically ~/.dsh/settings.yaml or in your project root):

ui-onboarding:
  welcomeNoticeVersion: 2026-08-13.1

llm-pi-ai:
  providers:
    openrouter:
      apiKeyEnv: OPENROUTER_API_KEY
    ollama:
      displayName: Ollama
      api: openai-completions
      baseURL: http://127.0.0.1:11434/v1
      models:
        - id: ornith-1.5:ctx
          contextWindow: 16000
          maxTokens: 4096
      apiKeyEnv: OLLAMA_API_KEY

agent-default-model:
  provider: ollama
  model: ornith-1.5:ctx

agent-presets:
  default: minimal

Breakdown of the Configuration

• ui-onboarding: Pins the onboarding notice version (2026-08-13.1), preventing introductory dialogs from popping up on subsequent web console launches.
• llm-pi-ai: Configures the underlying LLM provider adapter. DSH wraps the provider abstraction and streaming engine directly from Mario Zechner's open-source pi project into a Cordis plugin. Rather than maintaining custom client drivers for each inference backend, DSH reuses an existing upstream module, illustrating the practical composability of the open-source ecosystem.
  • openrouter: Preserved as a cloud fallback provider whenever you need to benchmark or handle tasks exceeding local model capabilities.
  • ollama: Points DSH to Ollama's local OpenAI-compatible completions endpoint (http://127.0.0.1:11434/v1).
  • models: Explicitly registers our custom ornith-1.5:ctx model with two critical runtime parameters:
  • contextWindow: 16000: Informs DSH of our 16K context ceiling (mirroring the num_ctx 16384 compiled into our Ollama Modelfile). This enables DSH to compute and display context utilization accurately in the web UI (such as ~10.6K / 16K) and trigger automated compactions before context overflows.
  • maxTokens: 4096: Sets the maximum generation ceiling for a single turn. While developers sometimes enter the base model's advertised architectural capacity here (such as 32000), maxTokens in DSH governs the single-response completion budget. Capping it to a realistic threshold like 4,096 tokens ensures individual outputs never exceed remaining context headroom or trigger runaway loops.
  • apiKeyEnv: Ollama does not require an API key for local inference, but DSH checks for an environment variable name; pointing to OLLAMA_API_KEY (even if empty) satisfies the schema.
• agent-default-model: Directs DSH to boot immediately using our local Ollama model as the primary reasoning engine.
• agent-presets: Sets the default agent execution preset to minimal, activating the lightweight minimal preset on every turn.

---

7. Step 5: Running the Local Agent in Practice

With settings.yaml saved and Ollama running in the background, launch the DeepSeek Harness web console:

dsh web

The web console launches locally, ready to pair with our ornith-1.5:ctx model running on the 8GB RTX 4070.

To test the agent under realistic conditions, we give it a practical software engineering task on an existing codebase:

"Inspect the local calculator web application (C:\Local\Dev\dsh\calculator), analyze its structure, diagnose any failing operations, and write an AUDIT.md report documenting your findings."

Phase 1: Starting with Minimal Mode

Because our 8GB mobile GPU restricts our local model to a 16K context window, our initial instinct is to minimize prompt bloat at all costs. We start the session using DSH's Minimal mode preset.

In Minimal mode, initial resource consumption is low:

• Tool definitions consume only ~971 tokens (less than 6% of our 16K context window).
• The system prompt takes a negligible ~16 tokens.
• Generation throughput is fast at ~17 tokens per second, with an average Time to First Token (TTFT) of 1.5 seconds.
• Over 90% of the context window remains available for model reasoning.

However, file operations fail when the agent attempts to record its findings on disk:

The limitation lies in the tools provided by the minimal preset. Minimal mode relies on str_replace_editor and persistent bash. While str_replace_editor works well for targeted replacements in existing files, its schema constraints are rigid when asked to create or format new files. When Ornith-1.5 attempts to write the audit file to disk, it produces recurring schema validation errors:

Error: invalid arguments: "new_str" must match exactly one oneOf branch (matched 0); "old_str" must match exactly one oneOf branch (matched 0)

Switching to the Trajectory tab in the DSH web interface exposes how the agent attempts to cope with this failure:

1. Repetitive Tool Failures: Ornith-1.5 retries the file write through str_replace_editor, but repeatedly hits schema rejection (INVALID_ARGS).
2. Context Guardrails Intervene: DSH's active repeat-tool-reminder plugin detects the loop and injects an inline context message warning the model that it is repeating identical failed calls.
3. Shell Fallbacks: While Ornith-1.5 recognizes the error, the minimal preset offers no alternative file creation tools. The model falls back to executing raw PowerShell (pwsh) scripts to write files character by character and reading back hex byte sequences (23 # 20 43 C) to verify output integrity.

In practice, while Minimal mode keeps tool schemas under 1K tokens, its editing surface is too rigid for repository maintenance. The preset lacks the necessary file manipulation tools for an end-to-end audit.

---

Phase 2: Switching to Standard Mode

To provide the tools necessary for proper software engineering, we switch our session preset from Minimal mode to Standard mode directly in the DSH interface.

Standard mode provides a full development toolset with dedicated read, write, edit, and interactive user dialog tools (ask_user). File operations proceed without schema errors:

However, tool schema overhead increases significantly:

• The expanded tool schemas consume ~6.9K tokens out of our 16K limit (over 43% of total context).
• Together with the ~1.8K system prompt, more than half of the context window is consumed before reading project files.
• Generation speed drops from 17 tokens/s down to ~12 tokens/s, and average TTFT increases to ~3.9 seconds.

Code Reasoning and Bug Localization

With dedicated file inspection tools available, the model traces the bug accurately.

The agent uses read to examine app.js and index.html. It identifies that in the calculator app, typing "8+8" unexpectedly displays "88" instead of performing addition:

Ornith-1.5 constructs a detailed step-by-step state trace. Using DSH's interactive prompt dialog (ask_user), the agent presents its findings clearly to the user, proposing Option A and asking for confirmation before making edits. Once approved, Ornith-1.5 applies the fix cleanly using the edit tool.

The Context Ceiling: Auto-Compactions in Action

While the code fix succeeded, inspecting the execution trajectory highlights the consequence of carrying ~6.9K tokens of tool schemas:

After just two turns and eleven steps:

• Total context utilization quickly surpasses 66% (~10.6K / 16K) and approaches saturation.
• DeepSeek Harness begins triggering frequent automatic context compactions (COMPACTED: summary is not smaller than shadowed content...) to prevent context overflow.
• Re-evaluating 10K+ tokens on every turn adds noticeable latency to local inference on the RTX 4070.

Empirical Validation of the VRAM Arithmetic

Throughout these multi-turn test runs across both Minimal and Standard modes, monitoring GPU telemetry via nvidia-smi provided a direct empirical confirmation of our theoretical model from Section 4:

The observed VRAM allocation stabilized at approximately 7.6 GB, closely matching our 7.8 GB calculation within 200MB of runtime variance.

More importantly, generation speed held steady at 17 tokens/s in Minimal mode and 12 tokens/s in Standard mode. If total memory consumption had crossed the 8.0 GB physical boundary, Windows unified memory manager would have immediately paged memory buffers across the PCIe bus into shared system RAM. That memory bus penalty causes generation throughput to plummet to 1-3 tokens/s. The sustained double-digit token generation rate confirms that our 9B model weights and the entire 16K KV cache remained 100% GPU-resident at all times.

---

The Engineering Takeaway: Fine-Tuning the Preset Sweet Spot

This hands-on experiment demonstrates the core dilemma of local AI agents on consumer hardware:

Dimension	Minimal Mode	Standard Mode
Tool Context Footprint	~971 tokens (<6% of 16K)	~6.9K tokens (~43% of 16K)
Inference Performance	~17 tok/s (TTFT 1.5s)	~12 tok/s (TTFT ~3.9s)
Code Reasoning & Tooling	Basic tools; fragile on file creation	Rich tools (read, write, edit, ask_user); deep reasoning
Bottleneck / Failure Mode	Schema errors (str_replace_editor), clunky workarounds	Rapid context saturation, frequent auto-compactions

Neither extreme is optimal out of the box for an 8GB GPU. Minimal mode leaves ample context but lacks reliable tools for multi-file development. Standard mode provides capable tooling and deep reasoning, but its ~6.9K schema footprint consumes valuable context that is critical for multi-turn reasoning and complex problem solving.

DeepSeek Harness avoids this rigid binary through its preset and profile system.

Instead of staying locked into either built-in preset, developers can fine-tune a custom preset specifically for local hardware:

1. Strip out unnecessary tools that are irrelevant to local debugging tasks (such as web search, browser automation, subagent delegation, and telemetry).
2. Retain the core filesystem tools that proved effective (read, write, edit, and interactive prompts), keeping tool schema overhead around ~2K tokens.
3. Reserve 12K+ tokens for conversation history, file contents, and extended reasoning loops.

Most importantly, because DSH manages capabilities via Cordis fibers, this preset tuning can be adjusted on the fly without even restarting the harness. This dynamic modularity makes it possible to find the exact sweet spot for any hardware budget.

Alternative Interface: Creating a Dedicated TUI Profile with dsh-TUI

Because DeepSeek Harness is a true meta-harness, its frontend interfaces are completely decoupled from its execution microkernel. You are never locked into a web browser.

To see how DSH's profile system works in practice (as we defined in Section 5), let's create a dedicated profile that replaces the web dashboard with an interactive Terminal User Interface (TUI).

Among the growing number of community TUI plugins, one particularly popular choice in China is dsh-TUI (@deepseek-harness-tui/dsh-tui). It brings a full-screen, Claude Code-style terminal experience to DeepSeek Harness, complete with streamed markdown, context usage gauges, and TPS metrics.

To configure and launch it, we declare a new profile named dsh-tui and add the plugin:

dsh plugin --profile dsh-tui add @deepseek-harness-tui/dsh-tui

dsh --profile dsh-tui

Because DSH treats the session as an append-only event stream, conversational state is completely independent of the display layer. If your terminal session disconnects or you want to pick up a previous task later, you can resume it directly by its session ID:

Resume with the command below:
dsh-tui --resume 6661d456-8dd1-49ad-bdf0-27bca9609574

This example illustrates the practical utility of DSH profiles: switching from the web interface to a terminal UI requires no dependency changes or environment reconfiguration, only launching under a different profile flag.

---

8. Best Practices for 8GB Local Agents

Working with constrained hardware requires disciplined operational habits:

1. Monitor VRAM Residency and Address Latency

Keep an eye on GPU memory during multi-step runs:

nvidia-smi -l 2

If memory consumption exceeds 8GB, Windows will automatically page memory into shared system RAM. If generation speed suddenly drops from 15 tokens/sec to 2-3 tokens/sec, your KV cache has spilled onto the CPU bus.

Even when fully GPU-resident, our setup averaged a TTFT of 1.5 to 3.9 seconds and 12 to 17 tokens/sec across our test runs. If you need snappier generation for interactive workflows, consider two optimizations:

• Fine-tuning Ollama parameters: Enabling Flash Attention (OLLAMA_FLASH_ATTENTION=1) or adjusting num_batch in your Modelfile can reduce memory bandwidth bottlenecks during prompt evaluation.
• Selecting a smaller model: Stepping down from a 9B model to a dedicated 7B model (such as Qwen2.5-Coder 7B) or an edge-focused architecture (such as Gemma 4 e2b) will significantly boost tokens per second while cutting prompt evaluation latency in half.

2. Fine-Tune the Tool Surface: Avoid Extremes

Avoid attaching extraneous MCP servers or plugins to local sessions. Every additional tool schema consumes context tokens and increases the probability of hallucinated arguments. At the same time, our Section 7 experiments proved that an off-the-shelf minimal preset with just bash and string replacement is too fragile for file creation, while the default Standard preset consumes ~6.9K tokens. The practical strategy is to fine-tune your own preset: preserve reliable file tools (read, write, edit) while pruning unused schemas (web search, subagents, telemetry) to keep tool overhead around ~2K tokens.

3. Use Hybrid Fallback Strategically

Because DSH defines multiple providers in settings.yaml, you are never locked into local inference. If you encounter a complex architectural refactor that exceeds the reasoning capabilities of a 9B model, you can switch the active model in the DSH web interface to OpenRouter (such as DeepSeek-V3 or Claude) for that specific prompt, and then switch back to Ollama for the implementation work.

4. Implement Automated Routing via LiteLLM

Switching models manually in the UI works for occasional tasks, but autonomous agents run best when routing happens automatically.

In a companion article, Building a Local-First AI Coding Agent with Open Tools and Adaptive Routing, we explored how to insert LiteLLM as an intelligent control plane (Layer 2) between the harness and the inference servers.

You can apply the exact same architecture to DeepSeek Harness:

• Configure DSH's provider in settings.yaml to point to a local LiteLLM proxy (http://127.0.0.1:4000/v1).
• Let LiteLLM inspect incoming requests: routine tool executions and file searches route to local Ollama at zero cost, while intricate architectural planning prompts automatically escalate to OpenRouter under strict per-session spend limits.
• This combines zero-cost local execution for routine loops with automated escalation to cloud models for complex reasoning.

---

9. Series Retrospective: From Meta-Framework to Local Agent

Over the course of this three-part series, we have traced the full lifecycle of modern agent infrastructure:

1. Part 1: Understanding Cordis explored the foundational microkernel created by Shigma. We saw how spatiotemporal composability, reverse cleanup stacks, and reactive contexts solve the chronic memory leaks of long-running JavaScript applications.
2. Part 2: DeepSeek Harness Architecture analyzed how DeepSeek turned Cordis into an operating system for AI agents. We untangled the harness terminology, contrasted DSH with turnkey tools like OpenCode and Pi, and examined its "everything-is-a-plugin" philosophy.
3. Part 3 (This Article) brought everything to life on consumer hardware. By pairing DSH's minimal preset with a context-tuned Ollama model, we proved that you do not need enterprise data centers or expensive cloud API budgets to run a functional, autonomous coding assistant.

DeepSeek Harness shows how modular systems engineering benefits local development. By separating runtime lifecycles, provider adapters, and tool presets, DSH allows developers to match agent overhead to physical hardware limits, making an 8GB GPU a viable environment for local pairing.

---

References & Links

• DeepSeek Harness GitHub Repository: github.com/deepseek-ai/deepseek-harness
• DeepSeek Harness Presets Guide: deepseekdsh.com/guides/modes
• dsh-TUI Terminal Interface: dshtui.com/en
• Community Plugin Directories: deepseekplugin.com | dsh-plugins.org
• Ollama Model Library: ollama.com/library
• Pi Coding Agent & Engine: pi.dev
• Part 1 of this Series: Understanding Cordis: The TypeScript Framework Built for Hot-Swapping Everything
• Part 2 of this Series: DeepSeek Harness: How DeepSeek Uses Cordis to Redefine Autonomous AI Agents
• Companion Article (Control Plane & Routing): Building a Local-First AI Coding Agent with Open Tools and Adaptive Routing