chore: bump github.com/maximhq/bifrost/core from 1.7.0 to 1.7.13 in /authbridge/authlib

[dependabot]

Bumps github.com/maximhq/bifrost/core from 1.7.0 to 1.7.13.

Release notes

Sourced from github.com/maximhq/bifrost/core's releases.

Core v1.7.13

Core Release v1.7.13

• feat: support Gemini's server-side toolCall/toolResponse parts with thoughtSignature round-trip fidelity - server-side search rounds now surface as web_search_call items carrying their own call ID and queries, unmapped tool types are preserved on the native round-trip instead of being dropped, and each thoughtSignature appears exactly once across the reconstructed parts so Gemini accepts the replayed turn
• feat: async 3D generation on Runware via /videos plus a raw /runware_passthrough route - taskType is now read from extra_params so any Runware async task can be driven through /videos (the 16:9 1080p width/height defaults now apply only to videoInference), outputs.files[].url is surfaced as VideoOutput URLs with the content type derived from the file extension, and the passthrough route forwards raw task arrays for capabilities with no first-class Bifrost surface such as upscaling and background removal
• feat: surface Runware's provider-reported per-task cost across image, video/3D and passthrough so pricing uses the exact figure verbatim instead of a datasheet estimate - this matters for task types like 3D that have no datasheet rate; when no cost is reported the behavior is unchanged
• feat: send s3:// image and document references to Bedrock Converse as the s3Location source member instead of downloading the bytes and re-uploading them - Converse resolves the object itself, which skips a round trip and the 25 MiB inline cap entirely. Image format is derived from the object extension since nothing is fetched and there is no Content-Type to read, and an extension-less object is rejected up front rather than producing an opaque 400
• feat: resolve Vertex URL sources per model family rather than inlining everything - a gs:// URI is now forwarded to Gemini/Gemma as fileData.fileUri (the documented form, resolved under the caller's own project IAM, and the only thing that keeps multi-hundred-MB video inputs viable) and read from Cloud Storage with the request key's own Google credentials for Claude-on-Vertex, which accepts base64 sources only. http(s) is still always fetched: forwarding one was measured against the harness and Vertex rejected every endpoint shape with URL_REJECTED-REJECTED_FC_TOO_MANY_PENDING
• fix: allow Vertex AI to send function declarations and a Google Search tool in the same request without includeServerSideToolInvocations - Vertex accepts the combination natively, so Google Search was being dropped for no reason, and search localization via RetrievalConfig.LatLng is now preserved when both tool types are present
• fix: prefer function declarations over Google Search when tool combination is disabled on Gemini - Google's tool combination is Preview and Gemini 3 only (https://ai.google.dev/gemini-api/docs/generate-content/tool-combination), so on every other model one of the two tool types has to be dropped. Function declarations now win: they carry the caller's own tools, or the ones Bifrost's MCP gateway synthesized from their connected servers, and dropping those leaves the model unable to invoke them at all while it answers as though the capabilities never existed. Dropping Google Search only costs grounding, so the model still answers, just without citations. One is disabled, the other is degraded. Set include_server_side_tool_invocations to send both. A lone Google Search tool still converts back correctly, and retrievalConfig is only emitted when a search tool actually survived conversion Breaking on the Gemini API surface: a request carrying both function declarations and Google Search without include_server_side_tool_invocations previously kept Google Search and dropped the function declarations. It now does the opposite. Set include_server_side_tool_invocations to true to send both, which is supported on Gemini 3 models. Vertex is unaffected, since it accepts the combination natively and drops neither.
• fix: always emit a Gemini candidate carrying its finish reason on generateContent, even when nothing visible was generated - a thinking model that spends its whole output budget before emitting a token is a successful 200 with an empty answer, but Candidates is omitempty, so dropping that candidate produced a body with no candidates key at all and left a lone usageMetadata object that every Gemini-shaped client dereferences blind
• fix: drop payload-free Gemini parts when assembling a candidate - every Part field is omitempty, so such a part marshals to exactly {}; the harness observed one on the wire when a transcription request for an unintelligible tone came back as parts:[{}], where it is noise a client will try to read and it masks the contentless case by making the parts slice look non-empty
• fix: accept a bare model identifier on Bedrock rerank by synthesizing the foundation-model ARN from the resolved region - Rerank is the one Bedrock surface that names its model by ARN rather than by bare ID, so all three rerank drop-ins in the provider harness 400'd on amazon.rerank-v1:0. The partition is derived from the region (aws, aws-cn, aws-us-gov) so GovCloud and China build a correct ARN, and an explicit ARN still passes through untouched
• fix: stop stripping file_url from OpenAI-shaped chat file blocks on marshal - dropping it produced {"type":"file","file":{}} and an upstream complaint about a missing file_id, which hid the fact that a source had been discarded. Providers that cannot take a URL now say so by name, and any OpenAI-compatible endpoint that does accept one keeps working without a Bifrost change
• fix: leave URL content sources Bifrost cannot download in place on the OpenAI and native-Anthropic paths instead of failing the request - only http(s) is fetched, and whether a gs://, s3:// or scheme-less reference is usable is the provider's call, so the source now travels as {"type":"url"} and the platform answers for itself

Installation

go get github.com/maximhq/bifrost/core@v1.7.13

---

This release was automatically created from version file: core/version

Core v1.7.12

Core Release v1.7.12

• feat: support Gemini's server-side toolCall/toolResponse parts with thoughtSignature round-trip fidelity - server-side search rounds now surface as web_search_call items carrying their own call ID and queries, unmapped tool types are preserved on the native round-trip instead of being dropped, and each thoughtSignature appears exactly once across the reconstructed parts so Gemini accepts the replayed turn
• feat: async 3D generation on Runware via /videos plus a raw /runware_passthrough route - taskType is now read from extra_params so any Runware async task can be driven through /videos (the 16:9 1080p width/height defaults now apply only to videoInference), outputs.files[].url is surfaced as VideoOutput URLs with the content type derived from the file extension, and the passthrough route forwards raw task arrays for capabilities with no first-class Bifrost surface such as upscaling and background removal
• feat: surface Runware's provider-reported per-task cost across image, video/3D and passthrough so pricing uses the exact figure verbatim instead of a datasheet estimate - this matters for task types like 3D that have no datasheet rate; when no cost is reported the behavior is unchanged
• feat: send s3:// image and document references to Bedrock Converse as the s3Location source member instead of downloading the bytes and re-uploading them - Converse resolves the object itself, which skips a round trip and the 25 MiB inline cap entirely. Image format is derived from the object extension since nothing is fetched and there is no Content-Type to read, and an extension-less object is rejected up front rather than producing an opaque 400
• feat: resolve Vertex URL sources per model family rather than inlining everything - a gs:// URI is now forwarded to Gemini/Gemma as fileData.fileUri (the documented form, resolved under the caller's own project IAM, and the only thing that keeps multi-hundred-MB video inputs viable) and read from Cloud Storage with the request key's own Google credentials for Claude-on-Vertex, which accepts base64 sources only. http(s) is still always fetched: forwarding one was measured against the harness and Vertex rejected every endpoint shape with URL_REJECTED-REJECTED_FC_TOO_MANY_PENDING
• fix: allow Vertex AI to send function declarations and a Google Search tool in the same request without includeServerSideToolInvocations - Vertex accepts the combination natively, so Google Search was being dropped for no reason, and search localization via RetrievalConfig.LatLng is now preserved when both tool types are present
• fix: prefer function declarations over Google Search when tool combination is disabled on Gemini - Google's tool combination is Preview and Gemini 3 only (https://ai.google.dev/gemini-api/docs/generate-content/tool-combination), so on every other model one of the two tool types has to be dropped. Function declarations now win: they carry the caller's own tools, or the ones Bifrost's MCP gateway synthesized from their connected servers, and dropping those leaves the model unable to invoke them at all while it answers as though the capabilities never existed. Dropping Google Search only costs grounding, so the model still answers, just without citations. One is disabled, the other is degraded. Set include_server_side_tool_invocations to send both. A lone Google Search tool still converts back correctly, and retrievalConfig is only emitted when a search tool actually survived conversion Breaking on the Gemini API surface: a request carrying both function declarations and Google Search without include_server_side_tool_invocations previously kept Google Search and dropped the function declarations. It now does the opposite. Set include_server_side_tool_invocations to true to send both, which is supported on Gemini 3 models. Vertex is unaffected, since it accepts the combination natively and drops neither.
• fix: always emit a Gemini candidate carrying its finish reason on generateContent, even when nothing visible was generated - a thinking model that spends its whole output budget before emitting a token is a successful 200 with an empty answer, but Candidates is omitempty, so dropping that candidate produced a body with no candidates key at all and left a lone usageMetadata object that every Gemini-shaped client dereferences blind
• fix: drop payload-free Gemini parts when assembling a candidate - every Part field is omitempty, so such a part marshals to exactly {}; the harness observed one on the wire when a transcription request for an unintelligible tone came back as parts:[{}], where it is noise a client will try to read and it masks the contentless case by making the parts slice look non-empty
• fix: accept a bare model identifier on Bedrock rerank by synthesizing the foundation-model ARN from the resolved region - Rerank is the one Bedrock surface that names its model by ARN rather than by bare ID, so all three rerank drop-ins in the provider harness 400'd on amazon.rerank-v1:0. The partition is derived from the region (aws, aws-cn, aws-us-gov) so GovCloud and China build a correct ARN, and an explicit ARN still passes through untouched
• fix: stop stripping file_url from OpenAI-shaped chat file blocks on marshal - dropping it produced {"type":"file","file":{}} and an upstream complaint about a missing file_id, which hid the fact that a source had been discarded. Providers that cannot take a URL now say so by name, and any OpenAI-compatible endpoint that does accept one keeps working without a Bifrost change
• fix: leave URL content sources Bifrost cannot download in place on the OpenAI and native-Anthropic paths instead of failing the request - only http(s) is fetched, and whether a gs://, s3:// or scheme-less reference is usable is the provider's call, so the source now travels as {"type":"url"} and the platform answers for itself

Installation

</tr></table> 

... (truncated)

Commits

• 169647c reasoning fix (#6292)
• 0c60a9b core version cut (#6291)
• e06b324 gemini tool call fixes (#6280)
• 01df4af fixes params sequence in chat completions (#6235) (#6274)
• 5e59157 file/image embedding flow fixes (#6239) (#6273)
• 53c8849 feat(gemini): support server-side toolCall/toolResponse parts with thoughtSig...
• 3ff8ef4 fix: bedrock files handling in inference (#5947) (#6271)
• 4fa86d0 reverting back the comment for new tags to burst cache
• c3386f6 table name change
• 0a8a38c Update changelog with new features and fixes
• Additional commits viewable in compare view

[evaline-ju]

@dependabot rebase

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

[huang195]

Not approving yet — this is blocked on a workspace file Dependabot cannot reach, and the fix is now open as #796.

The failure is not in the bifrost bump itself. Raising the module Go directives to 1.26.5 leaves authbridge/go.work at 1.26.4, and Go CI (authlib) is the only job that reads go.work (the cmd/* matrix and dependabot-tidy both set GOWORK: "off"), so it errors about four modules at once:

go: module . listed in go.work file requires go >= 1.26.5, but go.work lists go 1.26.4

#796 raises go.work and all seven module directives to 1.26.5. Worth noting a subtlety found while fixing it: bumping go.work alone is not sufficient, because actions/setup-go exports GOTOOLCHAIN=local itself and installs the version named by authlib/go.mod — a pinned 1.26.4 toolchain can never satisfy a go.work asking for 1.26.5.

Once #796 merges, rebase this and the go 1.26.5 lines here become no-ops, leaving just the bifrost bump.

Assisted-By: Claude Code

[evaline-ju]

@dependabot rebase

[huang195]

Approving now that #796 has landed — this was the one I held back while it was red.

Confirmed unblocked. The failure was never in the bifrost bump: raising the module Go directives to 1.26.5 left authbridge/go.work at 1.26.4, and Go CI (authlib) is the only job that reads go.work, so it errored about four modules at once. #796 raised go.work and all seven module directives together, and the go 1.26.5 lines have correspondingly vanished from this diff — they are no-ops now. 20 checks: 18 pass, 2 skipping (Spellcheck, tidy), 0 fail.

Verified the diff before approving, because #767 demonstrated that a Dependabot rebase can silently retarget a PR — there, 1.5.1 became 1.6.0 while an existing approval carried over, and it merged into an unsatisfiable requirements.txt. Checked here:

• Title still says 1.7.13, and the diff agrees. The build(deps): → chore: bump prefix change is Dependabot's newer title format, not a retarget.
• Every changed go.mod line accounted for: maximhq/bifrost/core 1.7.0 → 1.7.13 (direct in authlib, indirect in envoy/proxy) and buger/jsonparser 1.1.2 → 1.2.0 (indirect, pulled in transitively). Nothing else.

One observation, not blocking: the tidy job reports skipping on this PR, so dependabot-tidy did not run here. Not a problem in itself — Dependabot regenerated the go.sum files during its own rebase, and Go CI passes for all three affected modules — but worth a look at why the job's actor guard did not fire, given that workflow was just reworked in #789/#792.

Assisted-By: Claude Code