Skip to content

Refactor initializeTracers#847

Merged
mattklein123 merged 3 commits intomasterfrom
ac-tracing
Apr 28, 2017
Merged

Refactor initializeTracers#847
mattklein123 merged 3 commits intomasterfrom
ac-tracing

Conversation

@goaway
Copy link
Copy Markdown
Contributor

@goaway goaway commented Apr 26, 2017

No description provided.

Comment thread source/server/configuration_impl.cc Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you check to make sure we have test coverage on both of these branches? It might be better to combine this into the previous if check for easier coverage, but as long as we have coverage of both I'm fine with either way.

@mattklein123 mattklein123 merged commit ff83aec into master Apr 28, 2017
@mattklein123 mattklein123 deleted the ac-tracing branch April 28, 2017 23:14
mathetake added a commit that referenced this pull request Mar 3, 2026
**Description**

This removes the input api schema field in the filter config as it
shouldn't be a config and currently it is not really used. The input
schema is already determined by the specific API endpoint being used by
the Envoy AI Gateway, such as the unified OpenAI API at
`v1/chat/completions` or later the Anthropic Messages API we are
supporting at `anthropic/v1/messages`. This removes the confusion when
we are going to support other vendor pass through APIs like Anthropic.
We may need to consider deprecating the input `APISchema` defined on
`AIGatewayRoute` which is also not really used.

Related Issue: #847

---------

Signed-off-by: Dan Sun <dsun20@bloomberg.net>
Co-authored-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
mathetake added a commit that referenced this pull request Mar 3, 2026
**Description**

This commit adds support for the first party Anthropic API
api.anthropic.com in the project. Notably, this adds the passthrough
"translator" that captures the token usage as well as the API for the
Anthropic API key configuration which is slightly different from both
the existing APIKey security policy (authorization header) as well as
Azure API key (api-key header) in the sense that it requires the key
passed as "x-api-key" header.

**Related Issues/PRs (if applicable)**

#847

---------

Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants