refactor(skills/fork): multi-provider via CredentialBundle + CHANGELOG addendum#202
Merged
Merged
Conversation
…G addendum Phase D4 of the LLM backend upgrade. Closes the executor side of the multi-provider sub-agent / fork-mode plan by introducing a credential- bundle-aware fork runner that routes through any of the 6 providers (four API + two CLI) — the existing Anthropic-only ``make_default_fork_runner`` stays around for hosts that don't yet wire a bundle. skills/types.py - ``SkillMetadata.provider: Optional[str]`` — fork skills can declare their preferred provider; the runner picks the right client class. skills/fork.py - New ``make_credential_bundle_fork_runner(credentials, *, fallback_provider, fallback_model, max_tokens)``. Always returns a runner; credential failures surface as ``ForkResult(is_error=True)`` so the parent loop keeps running. - Provider routing: ``skill.metadata.provider`` → fallback_provider. - Client construction via ClientRegistry + ``_creds_to_client_kwargs`` shared with the pipeline path. - Records provider + model + token usage + cost_usd (when populated) in ``ForkResult.metadata``. tests/unit/test_fork_multi_provider.py (NEW) - 6 cases: runner returns unconditionally, skill provider routing, fallback_provider routing, missing-credentials structured error, unknown-provider structured error, model_override propagation. CHANGELOG.md — 2.0.0 entry gains a "Multi-provider sub-agent system" section + the fork runner / state slots / attach_runtime kwarg documented. Full suite: 3235 passed, 8 skipped, 0 failed. Phase D done. The executor is feature-complete for the LLM backend upgrade cycle: 6 providers in the registry, multi-provider sub-agent dispatch with parallel fan-out, credential propagation end-to-end, and a fork-mode runner that doesn't care about provider count. Next step: PyPI release. Plan reference: docs/llm-backend-upgrade-plan/07_rollout_phases.md (Phase D4). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Phase D4 of the LLM backend upgrade cycle — closes the executor side. Introduces a credential-bundle-aware fork-mode runner so fork skills can route through any of the 6 providers (four API + two CLI). The legacy `make_default_fork_runner` (Anthropic-only) stays around for hosts that haven't migrated to bundles.
What's new
Test plan
Phase D done. Executor is feature-complete for the LLM backend upgrade cycle. Next: PyPI release of v2.0.0.
Plan reference: `docs/llm-backend-upgrade-plan/07_rollout_phases.md` (Phase D4).