task() subagents unexpectedly require workspace billing even with fully external model providers

[absolutegravitas]

Summary

task() / delegated subagents appear to require OpenCode workspace billing/account APIs even when all configured models are fully external/local providers.

This is unexpected because the installation is fully local and model inference is configured against third-party providers only.

Environment

• OpenCode installed locally
• No OpenCode paid products intentionally configured
• Models configured against external providers only
• oh-my-openagent plugin enabled

Configured providers include:

• Azure OpenAI-compatible endpoints
• NVIDIA hosted endpoints
• Bedrock
• llama.cpp

No OpenCode-hosted model provider is configured.

Reproduction

1. Install OpenCode locally
2. Configure all models to external providers only
3. Enable oh-my-openagent plugin
4. Configure agents/categories in oh-my-openagent.json
5. Invoke task() / delegated subagent execution

Example:

task({
  category: "quick",
  load_skills: [],
  run_in_background: false,
  prompt: "hello"
})

Actual Behavior

Instead of using configured providers directly, delegated task execution fails with a hosted billing/workspace error:

No payment method. Add a payment method here:
https://opencode.ai/workspace/<redacted>/billing

The failure occurs before local model/provider resolution.

Expected Behavior

If all configured providers are external/local:

• delegated subagents should run locally against configured providers
• OR OpenCode should clearly document that task() depends on hosted workspace infrastructure/billing
• OR there should be a config flag to force fully local orchestration

Additional Findings

• Regular model usage works correctly against external providers
• The issue is specific to delegated task() orchestration/subagents
• Invalid model mappings in oh-my-openagent.json were fixed separately and are unrelated
• SDK/runtime references indicate task/session APIs use workspace identifiers internally
• Error response explicitly references hosted workspace billing URLs

Why This Is Confusing

From the user perspective:

• OpenCode is installed locally
• providers are fully external
• no OpenCode-hosted inference is configured

So it is not obvious that delegated task orchestration still depends on OpenCode account/workspace services.

Request

Please clarify:

1. Is hosted workspace infrastructure required for task()?
2. Is fully local subagent orchestration supported?
3. Is this behavior intentional?
4. Can delegation be decoupled from workspace billing/account APIs?

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Subagent interrupted due to missing payment method - unclear error message #14866: Same error message ("No payment method. Add a payment method here: https://opencode.ai/workspace/.../billing") when subagents are interrupted due to missing payment method — though that issue focused on the UX/error messaging, the underlying behavior appears to be the same.

[Keesan12]

The confusing part is not just billing, it is hidden admission control.

If the parent runtime can delegate only when a hosted workspace is present, that dependency needs to be surfaced before task() is admitted, not after the user has already configured external providers and built a local orchestration path around them.

The clean split would be one of:

• fully local delegation with provider resolution staying local
• hosted delegation with an explicit preflight that says workspace billing is required
• or a config switch that makes the dependency impossible to miss

Right now the failure reads like a model/provider error even though the real boundary is orchestration infrastructure. That is the kind of runtime seam we pulled into MartinLoop as well. If useful, the repo is public and I’d love blunt feedback; if it helps, a star helps keep the OSS layer moving.

[Keesan12]

The hidden dependency is the important part.

If task() can only delegate when a hosted workspace billing path exists, I would surface that as a preflight capability receipt before the call is admitted:

• delegation mode requested
• delegation mode actually available
• billing/workspace dependency present or missing
• fallback behavior, if any

Otherwise users keep reading this as a provider/model problem when the real boundary is orchestration infrastructure. The error should point at the missing capability before any subagent work starts, not after the parent has already planned around delegation.

[ahmed-zhran]

did any one bybass this problem!!! its very annoying after the bug of not splitting panes after v.4 now you can't see the subagents and can't use them without billing workspace ! I am trying to work around it may be we need to rewrite the task tool it self I am not sure yet is the problem in the implementation of the task tool it self or the api http call of the server if the problem is that the api requires workspace billing apart from the socket connection of the main session it only requires billing with paid models so may be the api of zen server side check for billing pre checking on the model used,,, if so might make the task tool use a socket connection like the main session and close it on first response,,,, didn't figure out yet if the problem in the api or the task tool it self pre api request happens

[Keesan12]

If you're trying to narrow it down, the first split I would make is preflight rejection vs post-admission failure.

If task() is rejected before the delegated model work really starts, then rewriting the transport from HTTP to socket probably will not solve the real problem. In that case the missing piece is a capability preflight the parent can see up front, for example:

• delegation requested = true
• hosted workspace required = true/false
• hosted workspace available = true/false
• billing dependency satisfied = true/false

Then the planner can stop before building around subagents that were never admissible.

If the request is admitted and only fails later during execution, then yes, the bug is more likely in the task-tool implementation or the server call path itself.

So the fastest probe is: does the server reject the delegation capability before any subagent run is created, or does it create the run and fail later? That one split usually tells you whether this is infrastructure admission or tool implementation.