[Feature]: Expose current provider and model to agent processes/skills

[ardalis]

Problem

T3 supports multiple coding-agent providers/runtimes such as Claude Code, Codex, OpenCode, Cursor, and potentially others. One of the benefits of this architecture is that the same project and agent skills can be used regardless of which provider or model is selected.

However, a skill running within an agent does not appear to have a standard, reliable way to determine which T3 provider and model are currently executing it.

Individual runtimes may expose some of this information in provider-specific ways, but relying on those mechanisms makes otherwise portable skills provider-specific. Asking the LLM to identify itself is also not an authoritative source of runtime metadata.

T3 already knows the selected provider and model, so it would be useful to expose this information to the executing agent.

Example Use Case

Consider a shared skill for implementing GitHub issues.

From T3, I want to be able to select any supported provider/model and simply say:

Implement issue #123

The skill would perform a standard workflow such as:

1. Read the GitHub issue.
2. Mark the issue as being actively worked.
3. Add an agent-specific label.
4. Add a comment recording who/what has claimed the issue.
5. Create a branch.
6. Implement the issue.
7. Run appropriate tests and validation.
8. Push the branch and create a PR.
9. Update the issue's status.

For example, the skill might add:

agent:claude

and comment:

I'm Claude running model claude-opus-4-7. I'm taking ownership of this issue and starting work on it now.

If I instead start the same task using OpenCode backed by an Anthropic model, the exact same skill might produce:

agent:opencode

and:

I'm OpenCode running model anthropic/claude-opus-4-7. I'm taking ownership of this issue and starting work on it now.

Likewise, a Codex session could produce:

agent:codex

with the appropriate model recorded.

The skill should not need to know how to detect Claude Code vs. Codex vs. OpenCode, nor should it have to maintain provider-specific logic as T3 adds providers.

Related Issues / Suggestions

• #2481 Show the provider and model used for each assistant message
• #4192 Expose reasoning effort for custom Claude models

Proposed Solution

Expose the current T3 execution context to the agent process using environment variables (or some alternative reliable way to query the current T3 execution context. Environment variables may be the simplest implementation when the context is stable for the lifetime of the provider process, such as a get_execution_context() tool that could be invoked).

For example:

T3CODE_PROVIDER=claude
T3CODE_MODEL=claude-opus-4-7

or:

T3CODE_PROVIDER=opencode
T3CODE_MODEL=anthropic/claude-opus-4-7

These values should represent the actual T3 provider and model selected for the current execution, rather than values inferred by the agent.

Additional metadata could optionally be exposed where available:

T3CODE_PROVIDER=opencode
T3CODE_MODEL=anthropic/claude-opus-4-7
T3CODE_AGENT=build
T3CODE_MODEL_VARIANT=high
T3CODE_THREAD_ID=...
T3CODE_TURN_ID=...

Only T3CODE_PROVIDER and T3CODE_MODEL are necessary for the primary use case. The others are suggestions for metadata that may prove useful for tracing and more advanced skills.

Provider vs. Agent Terminology

I suggest distinguishing provider/runtime from agent/mode.

For example, with OpenCode:

T3CODE_PROVIDER=opencode
T3CODE_MODEL=anthropic/claude-opus-4-7
T3CODE_AGENT=build

Here, opencode identifies the integration/runtime T3 launched, while build identifies an OpenCode-specific agent or mode.

This avoids overloading the term "agent" and gives portable skills a stable identifier for the T3 integration being used.

Why T3 Should Provide This

A skill could attempt to detect its environment itself, but this has several problems.

For example, checking whether claude, codex, or opencode executables exist does not identify the current provider because a development environment may have all of them installed.

Reading provider-specific configuration or session files couples the skill to implementation details of each provider.

Asking the model which model it is running is also not necessarily authoritative.

T3 is the component that selected/launched the provider and model, so it is the natural source of truth for this information.

This also establishes a clean abstraction boundary:

T3
|
| provider/model execution context
v
Agent Runtime
|
v
Portable Skill

The skill only consumes normalized T3 metadata and does not need to understand how each underlying provider represents it.

Other Potential Uses

GitHub issue ownership is just one example. Exposing execution metadata would also enable portable skills to:

• Record agent/model provenance in pull requests.
• Add agent/model information to commits or generated artifacts.
• Emit telemetry about which providers and models perform particular tasks.
• Maintain audit trails for autonomous agent activity.
• Debug behavior differences between providers/models.
• Select provider-specific behavior only when genuinely necessary.
• Coordinate multiple autonomous agents working against the same repository.
• Record which agent/model produced a particular change.
• Build metrics around agent/model effectiveness.
• Reproduce or investigate failed agent runs.

This becomes increasingly useful as T3 supports more interchangeable providers and models.

Desired Behavior

Given:

T3 provider: OpenCode
Model: anthropic/claude-opus-4-7

a skill invoked by that session should be able to obtain authoritative values equivalent to:

T3CODE_PROVIDER=opencode
T3CODE_MODEL=anthropic/claude-opus-4-7

without:

• Provider-specific detection logic.
• Parsing T3 internal files.
• Parsing provider configuration files.
• Inferring the model from installed executables.
• Asking the LLM to identify itself.
• Requiring the user to manually provide these values in the prompt.

The same skill should then work unchanged when the user switches the T3 session to Claude Code, Codex, OpenCode, or another supported provider.

Related Issues

This seems related to previous/current work around model provenance and attribution:

• [Feature]: Show the provider and model used for each assistant message #2481 — Show the provider and model used for each assistant message.
• [Bug]: Agents panel mislabels model for depth-2 (nested) agent spawns — shows session default instead of actual serving model #6026 — Model attribution for nested agents.
• [Feature]: Inherit a default provider and model from a parent directory (e.g. ~/Developer/Work vs ~/Developer/Personal) #6179 — Model/provider selection and defaultModelSelection.

The distinction from UI-level model attribution is that this request is specifically about making T3's known execution context available to the executing agent and its skills.

Alternative: Context File

Environment variables seem like the simplest interface, but another option would be for T3 to expose a small machine-readable context file and provide its location through an environment variable:

T3CODE_CONTEXT=/path/to/t3-context.json

For example:

{
"provider": "opencode",
"model": "anthropic/claude-opus-4-7",
"agent": "build",
"modelVariant": "high",
"threadId": "...",
"turnId": "..."
}

This might be preferable if the execution context is expected to grow or if some values can change during the lifetime of a session.

For the basic portable-skill use case, however, environment variables for provider and model would be sufficient.

Concerns

It's possible that within a given session, the model could change. Or a sub-agent could be spun up that is using a different model. In either of these cases, I'm intentionally leaving this out of scope. These do not impact my intended use case and if they're deemed important I expect a separate solution can be proposed to deal with them once this is in place.

Summary

T3 already knows which provider and model are executing a task. Exposing that information through a small, stable runtime contract would allow skills to consume it without knowing anything about the underlying provider.

At minimum:

T3CODE_PROVIDER=<provider>
T3CODE_MODEL=<model>

This would make it much easier to write truly portable T3 skills that work consistently across Claude Code, Codex, OpenCode, and future providers while retaining accurate provenance about which agent/model actually performed the work.