DSH model capability field loss

DSH Catalog Picker: reasoningEfforts Field Loss

Author
DeepSeekAgent.io Editorial Team
Published
Updated

The DeepSeek Harness model catalog makes models quick to add, but a catalog entry may not contain every capability declared by a custom provider. In DSH 0.2.1-rc.3, the community found that adding a model through Catalog Picker can silently drop a hand-authored reasoningEfforts field. Requests still succeed, while the editor says the model has no reasoning-effort levels.

This can be misdiagnosed as a model or relay that lacks reasoning. The route works; the missing piece is local capability metadata in the DSH model configuration.

Loss occurs on first adoption

When Picker creates a new model row, it copies a fixed set of fields it knows, such as:

  • id and name;
  • contextWindow and maxTokens;
  • catalog input modalities.

reasoningEfforts is absent from that fixed object. First-time additions, custom providers, self-hosted models, and relay routes can therefore lose the extension. The saved model materializes with reasoning: false, and Composer hides the effort selector.

Existing rows are often preserved because merge logic takes the old object from byId first. Remove and re-add the same model, and it follows the adoption path again.

Why the route still works

Model ID, Base URL, protocol, and authentication remain available, so the provider can answer. reasoningEfforts primarily tells the DSH UI and runtime which effort levels the user may choose; it is not necessarily required to connect the route.

Separate two validation questions:

  1. can the model be called;
  2. does Harness understand all of its capabilities?

A single successful response does not validate reasoning, image input, tool use, output limits, or cache metadata.

Recovering the declaration

Redeclare the effort levels in the per-model editor, or add reasoningEfforts to the matching model through a Profile patch or YAML configuration. Reopen model settings and Composer to confirm that the choices appear, then run a traced request and inspect the actual parameter.

Keep a structured diff before and after saving. Check whether capability arrays and extension fields survive, whether an object with the same model ID was replaced wholesale, whether remove-and-readd changes the result, and whether UI capability labels match outbound requests.

Better merge semantics for a picker

A catalog should supply defaults, not define the complete schema for user-owned models. A safer implementation should:

  • copy catalog defaults while retaining unknown user fields;
  • merge catalog updates by field instead of replacing the model object;
  • require confirmation before deleting a capability;
  • round-trip custom providers through save, reopen, and save again;
  • validate reasoning, vision, tool use, and cache as independent capabilities.

For DeepSeek V4.1 Flash, use the Harness model configuration guide to verify model ID, images, and reasoning parameters. See the DSH v0.2.1-rc.3 update for current release context.

References