Skip to content

Inherit Chief's model before a newly created Bot makes its first request #410

Closed

Description

@HongyeZhou

What happened

When Chief creates a new Bot, the new Bot initially runs using the default model instead of Chief's currently selected model. In my setup, that default model is not configured, so the UI shows a model error. The model is changed only after the failed attempt.

Chief already has a working model configuration, so creating a child should not trigger an avoidable call to an unconfigured default model.

Steps to reproduce

  1. Configure a working model for Chief while leaving the installation's default model unconfigured.
  2. Ask Chief to create a new Bot.
  3. Observe that the new Bot first attempts to run with the unconfigured default model.
  4. A model error appears in the UI before the model is subsequently changed.

Expected behavior

  • When Chief creates a Bot without an explicit model override, initialize the new Bot with Chief's current provider/model selection.
  • Apply that selection before the new Bot's first model request, including any automatic greeting or initial delegated work. Creating the Bot and changing its model afterward still allows the reported failure.
  • Preserve an explicitly supplied model override.
  • Keep the new Bot's model independently configurable afterward; this request is for inheritance at creation, not ongoing synchronization when Chief changes models.

Suggested verification

With Chief configured to use a working non-default model and the default model left unconfigured, create a new Bot and trigger its initial work. Its first request should use Chief's provider/model, with no request to the unconfigured default route and no transient missing-credentials error.

Environment and evidence

  • FlyBot core: 0.2.0, deployed checkout 9e6e2a0.
  • DeepSeek Harness: 0.2.0-rc.2, Web deployment.
  • Behavior reported by the user; the reporting agent has not independently reproduced the creation flow.
  • No screenshot or exact error text supplied for this occurrence.

Related: #365 proposes broader per-child harness/model configuration and parent inheritance. This report isolates the current first-run failure and the need to apply the inherited model before any execution.

Activity

  1. added 2 commits that reference this issue on Oct 19, 2026
    e4c1415
    cbce2b0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions