Skip to content

Users with IBM Consulting Advantage model access can't use it as a provider in DAM #6134

Open

Description

@jenna-winkler

Context

IBM Consulting users get model access through the IBM Consulting Advantage (ICA) gateway. Their team manages the keys, and regional instances keep client delivery work in approved environments. Several consulting users have asked to run DAM agents on it. One team got a Claude Code agent working with environment variables as a workaround. Another user already runs Codex on ICA locally. Research task #6013 asked whether this is possible, and these reports answer part of it.

Problem

ICA isn't a provider option in DAM. A consulting user must use a provider their team doesn't fund, or hand-wire environment variables that only someone who knows the gateway's API can set up. Teams that are only cleared to use ICA for client work can't use DAM there at all.

Goal

A user can pick ICA as a provider, paste their ICA key, and run an agent on ICA models with no manual setup.

User Stories

  • As a user, I want to add my ICA key as a provider so that my agents use the models my team already pays for.
  • As a user, I want to choose ICA models for an agent so that client work stays on an approved gateway.

Done when

AC-1 — ICA is a provider option

Given a user opens the provider setup in the web UI
When they look at the list of providers
Then they see an IBM Consulting Advantage option that asks for an API key

AC-2 — An agent runs on ICA

Given a user has added a valid ICA key
When they create an agent on an ICA model and send it a message in chat
Then the agent replies

AC-3 — A bad key is caught

Given a user enters an invalid ICA key
When they save it
Then they see an error saying the key was rejected

Open Questions

  • Which harnesses work: Codex only, or Claude Code too? The reports conflict.
  • The global instance only, or regional instances too?
  • Does ICA report usage, so the spend screens stay accurate?
  • Who owns the gateway, and do they need to approve access from DAM?

Additional resources

Follow up

Activity

  1. BrUn3y commented on Nov 2, 2026

    @BrUn3y
    Contributor

    Hey @jenna-winkler

    I validated Claude Code on DAM against the global ICA endpoint by switching an existing agent from LiteLLM to ICA. This provides a working example for the Claude Code compatibility question.

    ICA also exposes an Anthropic-compatible Messages API, in addition to the OpenAI-compatible API mentioned in the issue:

    Base URL: https://api.servicesessentials.ibm.com
    Messages endpoint: POST /v1/messages
    Authentication: Authorization: Bearer
    Model discovery: GET /v1/models

    The working environment configuration was:

    ANTHROPIC_BASE_URL=https://api.servicesessentials.ibm.com
    ANTHROPIC_MODEL=claude-advantage-assist
    ANTHROPIC_SMALL_FAST_MODEL=claude-haiku-5-5[1m]
    CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1

    ANTHROPIC_DEFAULT_FABLE_MODEL=claude-advantage-assist
    ANTHROPIC_DEFAULT_OPUS_MODEL=claude-advantage-assist
    ANTHROPIC_DEFAULT_SONNET_MODEL=claude-advantage-assist
    ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-5-5[1m]

    The workaround used an anthropic-oauth connection template with a custom host and bearer credential. The environment was saved through agents.update, and the connection was assigned through connections.setAgentConnections.

    DAM regenerated these managed files:

    • /home/agent/.platform/runtime-env.json
    • /home/agent/.platform/pod-service-env.json

    No agent source files required manual changes. After restarting, the configuration persisted, an actual dam run completed successfully, and telemetry recorded claude-advantage-assist. Both the primary and fast models returned HTTP 200 in direct API tests.

    A few findings could help refine the implementation and acceptance criteria:

    • Discover models using the supplied key. A valid key rejected claude-haiku-4-5 with 403 team_model_access_denied, while the advertised claude-haiku-5-5[1m] worked. An unavailable model should produce a different setup error from an invalid key.
    • Validate both primary and fast models. A successful primary-model request does not establish access to the model used for auxiliary operations.
    • Verify persistence after restart. Provider configuration should survive agent restarts through DAM-managed settings.
    • Usage metadata is available. The Messages response included input, output, and cache token counts. This confirms token usage reporting at the API level; DAM spend calculations still need validation.

    This validation covers the global endpoint and the Claude Code harness. Regional endpoints and Codex were not tested in this setup.

    Image Image
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