Mixing self-hosted Qwen with Bedrock Claude costs you telemetry, not a rewrite

AWS has published a reference build that runs three specialised agents through a single Amazon Bedrock AgentCore container, two of them on Bedrock-hosted Claude models and one on a Qwen 3.5 9B endpoint the operator hosts on Amazon SageMaker AI ^{[1][6][7][8][9]}. The orchestration side of that split costs nothing extra to arrange; the cost accounting side is where the engineering lands ^[5][18].

The topology is deliberately mundane. An orchestrator on Claude Haiku 4.5 classifies intent and routes through Global cross-Region inference ^[7]. A budget agent on Claude Sonnet 4.6 produces 50/30/20 breakdowns with structured Pydantic output ^[8]. A financial analysis agent on Qwen 3.5 9B does stock analysis and portfolio construction with tool-calling, reached over a SageMaker real-time endpoint using the OpenAI-compatible API ^[9][11]. Routing is the Strands Agents agents-as-tools pattern, with fresh agent instances per invocation, and results return through the orchestrator ^[10][14]. Qwen runs on the vLLM deep learning container image vllm:0.22.1-gpu-py312-cu130 on an ml.g6e.2xlarge ^[12]. Deployment of the whole workflow goes through the bedrock-agentcore-starter-toolkit ^[15].

AWS frames the premise as mixing managed foundation models with your own cost-optimised or domain-specific models without rewriting the agent framework, and claims cost optimisation, data residency and model flexibility from one architecture ^[2][3]. On the evidence of the walkthrough, the framework claim holds: the same agents-as-tools code path fronts both providers ^[10]. What does not come free is everything around the model call.

Two seams show up. The first is authentication: the SageMaker OpenAI-compatible API expects a bearer token, tokens expire, and any long-running session therefore needs a refresh on every request, which the post handles with an httpx.Auth subclass ^[13]. The second is the one operators should care about more. AgentCore runtime instruments agents with OpenTelemetry automatically, but that instrumentation does not extend equally across providers ^[16]. Bedrock calls get full generative AI spans with token counts and no extra work ^[17]. SageMaker OpenAI-compatible endpoints reached through the Strands OpenAIModel class get no automatic token telemetry, because the instrumentation does not recognise them as generative AI calls at all ^[18]. Tokens burned by the Qwen agent are, in AWS's own word, invisible ^[19].

So in a three-agent system, two agents are metered for you and one is not ^[23]. That is a third of your model traffic, and specifically the third you moved off managed hosting to control cost, sitting outside your cost and latency dashboards until you write the spans yourself ^[23]. The provider-specific code in this build is not orchestration logic; it is auth refresh and telemetry ^[24].

Worth watching: whether the Strands OpenAIModel path gets recognised as a generative AI call by default instrumentation, which would remove the only structural reason this pattern needs custom observability code ^[18]. Also check Region availability before copying the stack, since Bedrock model access varies by Region and the build needs Haiku 4.5 and Sonnet 4.6 enabled, plus an IAM role carrying sagemaker:InvokeEndpoint and sagemaker:CallWithBearerToken ^[20][21]. Full source is in the accompanying GitHub repository ^[22].