Amazon Bedrock Mantle has noticeable turn latency; reuse AWS auth setup across requests

Problem

I use Codex with the built-in amazon-bedrock provider and the Bedrock Mantle endpoint. There is a noticeable pause before Codex starts responding, especially during tool loops with many model turns. The same model and endpoint feel faster through my Pi setup.

Codex appears to rebuild its AWS authentication setup before model requests instead of keeping it around for the session. With the default Bedrock configuration, it may do that setup twice: once to determine the regional Mantle URL and again to authenticate the request.

More importantly for an SSO profile, Codex calls credentials_provider.provide_credentials() directly when signing. This bypasses the SdkConfig identity cache that normally caches resolved AWS role credentials until near expiration. The SSO access token in ~/.aws/sso/cache is still reused, but the underlying SSO provider's provide_credentials() path calls AWS GetRoleCredentials. That makes a repeated AWS credential request per model request plausible from the source, rather than just repeated local file parsing.

Signing each request with SigV4 is normal and cheap; it must happen for every HTTP request. The concern is repeatedly resolving the credentials used to create that signature.

Suggested fix

Resolve credentials through a long-lived, expiration-aware AWS identity/credential cache, and reuse that cache across model requests. Reusing AwsAuthContext would avoid repeated provider construction, but is not sufficient by itself while sign() calls the raw provider directly. Codex could also determine the region without creating a separate authentication context.

Workaround I am testing

I configured Codex to run a Bedrock bearer-token command and cache its result for 10 minutes. I also set the Mantle URL explicitly so Codex does not load AWS authentication just to determine the region:

[model_providers.amazon-bedrock]
base_url = "https://bedrock-mantle.us-east-1.api.aws/openai/v1"

[model_providers.amazon-bedrock.auth]
command = "/path/to/cached-bedrock-token"
timeout_ms = 8000
refresh_interval_ms = 600000

The token command has a small cross-process cache, so Pi and separate Codex sessions can share the same token. This is promising, but it is a custom workaround. Users following the normal AWS_PROFILE/SSO setup may still experience the repeated authentication work.

<details>
<summary>Why I think Codex repeats this work</summary>

I confirmed the same code path in the current rust-v0.147.0 source:

1. Model request setup resolves the provider and its authentication:

core/src/client.rs#L959-L980

1. The Bedrock provider separately determines the runtime URL and request authentication:

model-provider/src/amazon_bedrock/mod.rs#L98-L115

1. Determining the default Mantle URL resolves AWS authentication to obtain the region:

model-provider/src/amazon_bedrock/mantle.rs#L57-L73

1. Resolving AWS authentication creates a new AwsAuthContext:

model-provider/src/amazon_bedrock/auth.rs#L33-L69

1. Creating that context reloads the AWS SDK configuration and obtains a credential provider:

aws-auth/src/lib.rs#L79-L110

AwsAuthContext::sign() calls the extracted provider's provide_credentials() directly. Although aws_config::defaults(...).load() creates an SdkConfig with a lazy identity cache, that cache is not used by this direct call and is dropped after loading the context.

For an SSO profile, the persistent ~/.aws/sso/cache contains the SSO access token. Resolving AWS role credentials is a separate step: SsoCredentialsProvider uses that access token to call AWS GetRoleCredentials. Normal AWS service clients place the resolved role credentials behind the SDK identity cache; this custom signing path currently does not.

</details>

<details>
<summary>What I observed</summary>

This started as a user-visible comparison rather than a controlled benchmark:

• Codex using the normal Bedrock AWS profile path felt noticeably slower before responding.
• Pi using a cached Bedrock bearer token felt faster against the same model and Mantle endpoint.
• In the Pi token script's timing log, generating a token averages about 730 ms and recent generations took about 1.2 seconds. Reading a cached token averages about 11 ms.

Those token timings are not measurements of Codex's AWS SDK path. They explain why I investigated authentication, but more instrumentation is needed to determine exactly how much Codex time is spent loading AWS configuration, fetching SSO role credentials, signing, and waiting for the first response byte.

I am currently testing the Codex command-auth workaround above and can provide follow-up measurements.

</details>

<details>
<summary>Environment and reproduction</summary>

Environment:

• Codex CLI observed: 0.146.1
• Confirmed code path remains in: 0.147.0
• Model: openai.gpt-5.6-sol, high reasoning
• Provider: built-in amazon-bedrock
• Endpoint: Bedrock Mantle in us-east-1
• Authentication: AWS profile backed by enterprise SSO
• OS: Arch Linux, x86_64
• Terminal: Ghostty 1.3.1
• codex doctor: overall status ok; endpoint reachable

Original configuration:

model_provider = "amazon-bedrock"
model = "openai.gpt-5.6-sol"

[model_providers.amazon-bedrock.aws]
profile = "my-sso-profile"
region = "us-east-1"

Reproduction:

1. Start Codex with the built-in amazon-bedrock provider and an AWS SSO profile.
2. Run a conversation that causes several model turns/tool calls.
3. Observe the pause before model output.
4. Compare or instrument repeated AWS configuration and credential resolution during request setup.

Related broader authentication/onboarding issue: #30133.

</details>