docs: complete docs revamp #136
Conversation
Summary by CodeRabbit
WalkthroughThis update introduces a comprehensive overhaul and expansion of Bifrost's documentation. It adds detailed guides, architecture and feature references, quick start materials, and advanced configuration docs, while removing and replacing older, less-structured documentation. Minor code changes include hiding an internal field from JSON output and removing a deprecated configuration field. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Docs
participant Bifrost Core
User->>Docs: Access README / Quick Start / Guides
Docs->>User: Provides navigation, setup, usage, troubleshooting
User->>Bifrost Core: Follows setup/config instructions
Bifrost Core-->>User: Serves API/model responses as configured
Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches
🧪 Generate Unit Tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 39
♻️ Duplicate comments (1)
docs/architecture/system-overview.md (1)
182-194: Same issue forProviderConfig/ConcurrencyAndBufferSizeThese structs now live without JSON tags in the codebase. Update the docs accordingly.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (44)
README.md(5 hunks)core/schemas/bifrost.go(1 hunks)core/schemas/mcp.go(0 hunks)docs/README.md(1 hunks)docs/architecture/README.md(1 hunks)docs/architecture/concurrency.md(1 hunks)docs/architecture/design-decisions.md(1 hunks)docs/architecture/performance.md(1 hunks)docs/architecture/request-flow.md(1 hunks)docs/architecture/system-overview.md(1 hunks)docs/benchmarks.md(1 hunks)docs/configuration/README.md(1 hunks)docs/configuration/core-config.md(1 hunks)docs/configuration/http-config.md(1 hunks)docs/contributing/README.md(1 hunks)docs/core-package.md(0 hunks)docs/fallbacks.md(0 hunks)docs/features/fallbacks.md(1 hunks)docs/features/integrations/README.md(1 hunks)docs/features/key-management.md(1 hunks)docs/features/logging.md(1 hunks)docs/features/mcp-integration.md(1 hunks)docs/features/memory-management.md(1 hunks)docs/features/networking.md(1 hunks)docs/features/observability.md(1 hunks)docs/features/plugins.md(1 hunks)docs/features/providers.md(1 hunks)docs/features/providers/README.md(1 hunks)docs/features/providers/anthropic.md(1 hunks)docs/features/providers/azure.md(1 hunks)docs/features/providers/openai.md(1 hunks)docs/guides/README.md(1 hunks)docs/guides/faq.md(1 hunks)docs/guides/troubleshooting.md(1 hunks)docs/http-transport-api.md(0 hunks)docs/logger.md(0 hunks)docs/mcp.md(0 hunks)docs/memory-management.md(0 hunks)docs/plugins.md(0 hunks)docs/providers.md(0 hunks)docs/quick-start/README.md(1 hunks)docs/quick-start/feature-comparison.md(1 hunks)docs/quick-start/go-package.md(1 hunks)docs/quick-start/http-transport.md(1 hunks)
💤 Files with no reviewable changes (9)
- core/schemas/mcp.go
- docs/fallbacks.md
- docs/core-package.md
- docs/logger.md
- docs/memory-management.md
- docs/providers.md
- docs/http-transport-api.md
- docs/plugins.md
- docs/mcp.md
🧰 Additional context used
🧠 Learnings (35)
📓 Common learnings
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:30-36
Timestamp: 2025-06-19T16:57:25.177Z
Learning: In the bifrost repository, Pratham-Mishra04 prefers to keep GitHub Actions workflows lean and trusts their controlled tagging process for core releases, avoiding unnecessary validation steps that they consider overkill.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#102
File: README.md:62-66
Timestamp: 2025-06-19T17:03:03.639Z
Learning: Pratham-Mishra04 prefers using the implicit 'latest' tag for the maximhq/bifrost Docker image rather than pinning to specific versions.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/bifrost.go:823-845
Timestamp: 2025-06-18T15:15:51.323Z
Learning: In the Bifrost project, the team prioritizes maintaining consistent error handling patterns over exposing detailed error context. All errors should be wrapped in the standard `BifrostError` structure rather than creating specific error types or exposing richer error details like exit codes or stderr output.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/schemas/bifrost.go:20-23
Timestamp: 2025-06-18T15:16:23.127Z
Learning: In the Bifrost project, BifrostConfig struct is never marshaled/unmarshaled, so serialization tags (json, yaml) are not needed for its fields.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:358-388
Timestamp: 2025-06-04T05:37:59.699Z
Learning: User Pratham-Mishra04 prefers not to extract small code duplications (around 2 lines) into helper functions, considering the overhead not worth it for such minor repetition.
core/schemas/bifrost.go (10)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/schemas/bifrost.go:20-23
Timestamp: 2025-06-18T15:16:23.127Z
Learning: In the Bifrost project, BifrostConfig struct is never marshaled/unmarshaled, so serialization tags (json, yaml) are not needed for its fields.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:223-231
Timestamp: 2025-06-10T11:06:06.670Z
Learning: The OpenAI `name` field on messages cannot be preserved when converting to Bifrost format because the `schemas.BifrostMessage` struct in bifrost/core does not support a Name field. This is a known limitation of the Bifrost core schema design.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#80
File: plugins/maxim/main.go:249-264
Timestamp: 2025-06-14T06:17:54.426Z
Learning: In the BifrostError struct, the Error field is a struct (not a pointer), so accessing bifrostErr.Error.Message, bifrostErr.Error.Code, and bifrostErr.Error.Type is safe without nil checks on the Error field itself. The Code and Type fields are of type *string.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/end_to_end_tool_calling.go:43-45
Timestamp: 2025-06-16T04:13:55.437Z
Learning: In the Bifrost codebase, errors returned from client methods like ChatCompletionRequest are of type BifrostError, not the standard error interface. For testing these errors, use require.Nilf instead of require.NoErrorf since BifrostError doesn't work with the standard error assertion methods.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/simple_chat.go:39-41
Timestamp: 2025-06-16T04:13:42.755Z
Learning: In the Bifrost codebase, errors returned from methods like ChatCompletionRequest are of type BifrostError (a custom error type) rather than the standard Go error interface. Therefore, require.Nilf should be used for error assertions instead of require.NoErrorf.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/bifrost.go:823-845
Timestamp: 2025-06-18T15:15:51.323Z
Learning: In the Bifrost project, the team prioritizes maintaining consistent error handling patterns over exposing detailed error context. All errors should be wrapped in the standard `BifrostError` structure rather than creating specific error types or exposing richer error details like exit codes or stderr output.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/complete_end_to_end.go:39-41
Timestamp: 2025-06-16T04:12:05.427Z
Learning: In the Bifrost system, error returns are of type `BifrostError` rather than the standard Go `error` interface. Therefore, use `require.Nilf(t, err, ...)` instead of `require.NoError(t, err)` when checking for errors in Bifrost function calls.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/schemas/bifrost.go:186-190
Timestamp: 2025-06-15T14:18:32.703Z
Learning: In core/schemas/bifrost.go, the ToolChoice UnmarshalJSON validation intentionally only checks for empty Type fields and lets providers handle validation of specific tool choice values. This architectural decision keeps schema validation focused on structure while allowing provider-specific semantic validation.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:96-101
Timestamp: 2025-06-15T13:50:41.418Z
Learning: In the Bifrost project, when a provider doesn't support a specific operation (like text completion), the IsBifrostError flag should be set to false to mark it as a provider-level error rather than a Bifrost framework error. This is intentional design for unsupported operations.
docs/features/providers.md (3)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:483-494
Timestamp: 2025-06-04T10:04:30.181Z
Learning: In the Anthropic provider (core/providers/anthropic.go), parallel tool calls support including the DisableParallelToolUse flag will be implemented in later commits as it's a relatively new feature that's not commonly used yet. The development approach prioritizes core functionality first.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:96-101
Timestamp: 2025-06-15T13:50:41.418Z
Learning: In the Bifrost project, when a provider doesn't support a specific operation (like text completion), the IsBifrostError flag should be set to false to mark it as a provider-level error rather than a Bifrost framework error. This is intentional design for unsupported operations.
docs/guides/README.md (3)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/bifrost.go:823-845
Timestamp: 2025-06-18T15:15:51.323Z
Learning: In the Bifrost project, the team prioritizes maintaining consistent error handling patterns over exposing detailed error context. All errors should be wrapped in the standard `BifrostError` structure rather than creating specific error types or exposing richer error details like exit codes or stderr output.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
docs/configuration/README.md (6)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/schemas/bifrost.go:20-23
Timestamp: 2025-06-18T15:16:23.127Z
Learning: In the Bifrost project, BifrostConfig struct is never marshaled/unmarshaled, so serialization tags (json, yaml) are not needed for its fields.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/bifrost.go:823-845
Timestamp: 2025-06-18T15:15:51.323Z
Learning: In the Bifrost project, the team prioritizes maintaining consistent error handling patterns over exposing detailed error context. All errors should be wrapped in the standard `BifrostError` structure rather than creating specific error types or exposing richer error details like exit codes or stderr output.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/tests/e2e_tool_test.go:29-30
Timestamp: 2025-06-04T04:58:12.239Z
Learning: In the Bifrost project, environment variables should be used only for secrets (like API keys), not for general configuration. Test parameters like provider and model can be hardcoded at the start of test files for predictability and consistency.
docs/contributing/README.md (7)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/bifrost.go:823-845
Timestamp: 2025-06-18T15:15:51.323Z
Learning: In the Bifrost project, the team prioritizes maintaining consistent error handling patterns over exposing detailed error context. All errors should be wrapped in the standard `BifrostError` structure rather than creating specific error types or exposing richer error details like exit codes or stderr output.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#135
File: docs/core-package.md:105-116
Timestamp: 2025-06-27T17:07:39.420Z
Learning: In Go, when importing a package, the identifier used to access it is determined by the `package` declaration in the Go source files, not the directory name. For the Bifrost project, the core directory files declare `package bifrost`, so importing `"github.com/maximhq/bifrost/core"` automatically makes it accessible as `bifrost.Init`, `bifrost.Ptr`, etc., without needing an explicit alias.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:30-36
Timestamp: 2025-06-19T16:57:25.177Z
Learning: In the bifrost repository, Pratham-Mishra04 prefers to keep GitHub Actions workflows lean and trusts their controlled tagging process for core releases, avoiding unnecessary validation steps that they consider overkill.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:89-119
Timestamp: 2025-06-10T11:00:02.875Z
Learning: In the Bifrost OpenAI integration (transports/bifrost-http/integrations/openai/types.go), the convertOpenAIContent function currently only handles the last image URL when multiple images are present in a content array. The user Pratham-Mishra04 has acknowledged this limitation and indicated it's part of a larger architectural issue that will be addressed comprehensively later, rather than with piecemeal fixes.
docs/quick-start/go-package.md (8)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#135
File: docs/core-package.md:105-116
Timestamp: 2025-06-27T17:07:39.420Z
Learning: In Go, when importing a package, the identifier used to access it is determined by the `package` declaration in the Go source files, not the directory name. For the Bifrost project, the core directory files declare `package bifrost`, so importing `"github.com/maximhq/bifrost/core"` automatically makes it accessible as `bifrost.Init`, `bifrost.Ptr`, etc., without needing an explicit alias.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/openai_test.go:1-2
Timestamp: 2025-06-16T04:29:53.409Z
Learning: In the Bifrost project, the user prefers to use `package main` for test files in the tests/core-providers directory rather than more descriptive package names like `coreproviders_test`.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/config/account.go:55-101
Timestamp: 2025-06-16T04:25:00.816Z
Learning: In the Bifrost test account implementation, the user prefers to let Bifrost itself handle missing API key errors rather than adding early validation in the GetKeysForProvider method.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/end_to_end_tool_calling.go:43-45
Timestamp: 2025-06-16T04:13:55.437Z
Learning: In the Bifrost codebase, errors returned from client methods like ChatCompletionRequest are of type BifrostError, not the standard error interface. For testing these errors, use require.Nilf instead of require.NoErrorf since BifrostError doesn't work with the standard error assertion methods.
Learnt from: connyay
PR: maximhq/bifrost#92
File: core/providers/utils.go:60-64
Timestamp: 2025-06-17T14:04:21.104Z
Learning: The bifrost codebase uses string alias types (like `type ContextKey string`) for context keys consistently across multiple packages including plugins/maxim/main.go and transports/bifrost-http/tracking/plugin.go. This pattern should be maintained for consistency rather than switching to the canonical struct{} approach.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/router.go:0-0
Timestamp: 2025-06-09T14:03:34.227Z
Learning: In the Bifrost HTTP transport layer (transports/bifrost-http/integrations/), request validation like checking for empty messages should be handled by the provider rather than at the transport layer. The transport layer should forward requests to Bifrost core/providers for validation.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
docs/quick-start/http-transport.md (4)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/router.go:0-0
Timestamp: 2025-06-09T14:03:34.227Z
Learning: In the Bifrost HTTP transport layer (transports/bifrost-http/integrations/), request validation like checking for empty messages should be handled by the provider rather than at the transport layer. The transport layer should forward requests to Bifrost core/providers for validation.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
docs/benchmarks.md (3)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/mcp.go:696-711
Timestamp: 2025-06-18T20:16:37.560Z
Learning: For the Bifrost MCP implementation, performance optimizations like caching tool discovery results should be deferred until after core functionality is complete. The author prefers to implement core features first and handle optimizations as follow-up work.
docs/README.md (6)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#135
File: docs/core-package.md:105-116
Timestamp: 2025-06-27T17:07:39.420Z
Learning: In Go, when importing a package, the identifier used to access it is determined by the `package` declaration in the Go source files, not the directory name. For the Bifrost project, the core directory files declare `package bifrost`, so importing `"github.com/maximhq/bifrost/core"` automatically makes it accessible as `bifrost.Init`, `bifrost.Ptr`, etc., without needing an explicit alias.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/bifrost.go:823-845
Timestamp: 2025-06-18T15:15:51.323Z
Learning: In the Bifrost project, the team prioritizes maintaining consistent error handling patterns over exposing detailed error context. All errors should be wrapped in the standard `BifrostError` structure rather than creating specific error types or exposing richer error details like exit codes or stderr output.
docs/quick-start/README.md (4)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#135
File: docs/core-package.md:105-116
Timestamp: 2025-06-27T17:07:39.420Z
Learning: In Go, when importing a package, the identifier used to access it is determined by the `package` declaration in the Go source files, not the directory name. For the Bifrost project, the core directory files declare `package bifrost`, so importing `"github.com/maximhq/bifrost/core"` automatically makes it accessible as `bifrost.Init`, `bifrost.Ptr`, etc., without needing an explicit alias.
docs/architecture/README.md (3)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
docs/guides/troubleshooting.md (4)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/bifrost.go:823-845
Timestamp: 2025-06-18T15:15:51.323Z
Learning: In the Bifrost project, the team prioritizes maintaining consistent error handling patterns over exposing detailed error context. All errors should be wrapped in the standard `BifrostError` structure rather than creating specific error types or exposing richer error details like exit codes or stderr output.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
README.md (15)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/tests/e2e_tool_test.go:29-30
Timestamp: 2025-06-04T04:58:12.239Z
Learning: In the Bifrost project, environment variables should be used only for secrets (like API keys), not for general configuration. Test parameters like provider and model can be hardcoded at the start of test files for predictability and consistency.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/router.go:0-0
Timestamp: 2025-06-09T14:03:34.227Z
Learning: In the Bifrost HTTP transport layer (transports/bifrost-http/integrations/), request validation like checking for empty messages should be handled by the provider rather than at the transport layer. The transport layer should forward requests to Bifrost core/providers for validation.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/providers/bedrock.go:241-252
Timestamp: 2025-06-04T09:07:20.867Z
Learning: In the Bifrost codebase, when working with AWS Bedrock provider authentication, the preference is to let AWS handle access key validation naturally rather than adding preemptive checks for empty/blank access keys. This allows AWS to provide its own authentication error messages which can be more informative than custom validation errors.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/config/account.go:55-101
Timestamp: 2025-06-16T04:25:00.816Z
Learning: In the Bifrost test account implementation, the user prefers to let Bifrost itself handle missing API key errors rather than adding early validation in the GetKeysForProvider method.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#85
File: core/providers/anthropic.go:150-156
Timestamp: 2025-06-15T16:07:53.140Z
Learning: In the Bifrost codebase, constructor functions are allowed to mutate input ProviderConfig objects in-place (e.g., setting default BaseURL values and trimming trailing slashes). This pattern is acceptable and doesn't need to be flagged as a code review issue.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#135
File: docs/core-package.md:105-116
Timestamp: 2025-06-27T17:07:39.420Z
Learning: In Go, when importing a package, the identifier used to access it is determined by the `package` declaration in the Go source files, not the directory name. For the Bifrost project, the core directory files declare `package bifrost`, so importing `"github.com/maximhq/bifrost/core"` automatically makes it accessible as `bifrost.Init`, `bifrost.Ptr`, etc., without needing an explicit alias.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/openai_test.go:1-2
Timestamp: 2025-06-16T04:29:53.409Z
Learning: In the Bifrost project, the user prefers to use `package main` for test files in the tests/core-providers directory rather than more descriptive package names like `coreproviders_test`.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/complete_end_to_end.go:39-41
Timestamp: 2025-06-16T04:12:05.427Z
Learning: In the Bifrost system, error returns are of type `BifrostError` rather than the standard Go `error` interface. Therefore, use `require.Nilf(t, err, ...)` instead of `require.NoError(t, err)` when checking for errors in Bifrost function calls.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/bifrost.go:823-845
Timestamp: 2025-06-18T15:15:51.323Z
Learning: In the Bifrost project, the team prioritizes maintaining consistent error handling patterns over exposing detailed error context. All errors should be wrapped in the standard `BifrostError` structure rather than creating specific error types or exposing richer error details like exit codes or stderr output.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/end_to_end_tool_calling.go:43-45
Timestamp: 2025-06-16T04:13:55.437Z
Learning: In the Bifrost codebase, errors returned from client methods like ChatCompletionRequest are of type BifrostError, not the standard error interface. For testing these errors, use require.Nilf instead of require.NoErrorf since BifrostError doesn't work with the standard error assertion methods.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/simple_chat.go:39-41
Timestamp: 2025-06-16T04:13:42.755Z
Learning: In the Bifrost codebase, errors returned from methods like ChatCompletionRequest are of type BifrostError (a custom error type) rather than the standard Go error interface. Therefore, require.Nilf should be used for error assertions instead of require.NoErrorf.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
docs/guides/faq.md (10)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/bifrost.go:823-845
Timestamp: 2025-06-18T15:15:51.323Z
Learning: In the Bifrost project, the team prioritizes maintaining consistent error handling patterns over exposing detailed error context. All errors should be wrapped in the standard `BifrostError` structure rather than creating specific error types or exposing richer error details like exit codes or stderr output.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/tests/e2e_tool_test.go:29-30
Timestamp: 2025-06-04T04:58:12.239Z
Learning: In the Bifrost project, environment variables should be used only for secrets (like API keys), not for general configuration. Test parameters like provider and model can be hardcoded at the start of test files for predictability and consistency.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/config/account.go:55-101
Timestamp: 2025-06-16T04:25:00.816Z
Learning: In the Bifrost test account implementation, the user prefers to let Bifrost itself handle missing API key errors rather than adding early validation in the GetKeysForProvider method.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/providers/bedrock.go:241-252
Timestamp: 2025-06-04T09:07:20.867Z
Learning: In the Bifrost codebase, when working with AWS Bedrock provider authentication, the preference is to let AWS handle access key validation naturally rather than adding preemptive checks for empty/blank access keys. This allows AWS to provide its own authentication error messages which can be more informative than custom validation errors.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:483-494
Timestamp: 2025-06-04T10:04:30.181Z
Learning: In the Anthropic provider (core/providers/anthropic.go), parallel tool calls support including the DisableParallelToolUse flag will be implemented in later commits as it's a relatively new feature that's not commonly used yet. The development approach prioritizes core functionality first.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:96-101
Timestamp: 2025-06-15T13:50:41.418Z
Learning: In the Bifrost project, when a provider doesn't support a specific operation (like text completion), the IsBifrostError flag should be set to false to mark it as a provider-level error rather than a Bifrost framework error. This is intentional design for unsupported operations.
docs/features/providers/openai.md (4)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:89-119
Timestamp: 2025-06-10T11:00:02.875Z
Learning: In the Bifrost OpenAI integration (transports/bifrost-http/integrations/openai/types.go), the convertOpenAIContent function currently only handles the last image URL when multiple images are present in a content array. The user Pratham-Mishra04 has acknowledged this limitation and indicated it's part of a larger architectural issue that will be addressed comprehensively later, rather than with piecemeal fixes.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/tests/e2e_tool_test.go:29-30
Timestamp: 2025-06-04T04:58:12.239Z
Learning: In the Bifrost project, environment variables should be used only for secrets (like API keys), not for general configuration. Test parameters like provider and model can be hardcoded at the start of test files for predictability and consistency.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:483-494
Timestamp: 2025-06-04T10:04:30.181Z
Learning: In the Anthropic provider (core/providers/anthropic.go), parallel tool calls support including the DisableParallelToolUse flag will be implemented in later commits as it's a relatively new feature that's not commonly used yet. The development approach prioritizes core functionality first.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:264-285
Timestamp: 2025-06-10T12:58:45.501Z
Learning: In the Bifrost OpenAI integration, tool calls should be allowed on any message role (not just assistant messages) and the downstream provider should handle validation. Users passing tool calls to non-assistant messages is considered deliberate behavior that should be preserved.
docs/features/fallbacks.md (4)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:96-101
Timestamp: 2025-06-15T13:50:41.418Z
Learning: In the Bifrost project, when a provider doesn't support a specific operation (like text completion), the IsBifrostError flag should be set to false to mark it as a provider-level error rather than a Bifrost framework error. This is intentional design for unsupported operations.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#89
File: transports/bifrost-http/integrations/genai/types.go:151-155
Timestamp: 2025-06-16T14:45:48.563Z
Learning: In transports/bifrost-http/integrations/genai/types.go, when SystemInstruction has an empty role, the user prefers to let the downstream provider (Google GenAI) handle validation and return errors, rather than implementing validation in the bifrost layer. This represents a design preference for delegating validation to the appropriate service rather than duplicating validation logic in the proxy layer.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:483-494
Timestamp: 2025-06-04T10:04:30.181Z
Learning: In the Anthropic provider (core/providers/anthropic.go), parallel tool calls support including the DisableParallelToolUse flag will be implemented in later commits as it's a relatively new feature that's not commonly used yet. The development approach prioritizes core functionality first.
docs/quick-start/feature-comparison.md (3)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
docs/configuration/http-config.md (3)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/tests/e2e_tool_test.go:29-30
Timestamp: 2025-06-04T04:58:12.239Z
Learning: In the Bifrost project, environment variables should be used only for secrets (like API keys), not for general configuration. Test parameters like provider and model can be hardcoded at the start of test files for predictability and consistency.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/router.go:0-0
Timestamp: 2025-06-09T14:03:34.227Z
Learning: In the Bifrost HTTP transport layer (transports/bifrost-http/integrations/), request validation like checking for empty messages should be handled by the provider rather than at the transport layer. The transport layer should forward requests to Bifrost core/providers for validation.
docs/architecture/system-overview.md (5)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/router.go:0-0
Timestamp: 2025-06-09T14:03:34.227Z
Learning: In the Bifrost HTTP transport layer (transports/bifrost-http/integrations/), request validation like checking for empty messages should be handled by the provider rather than at the transport layer. The transport layer should forward requests to Bifrost core/providers for validation.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/mcp.go:696-711
Timestamp: 2025-06-18T20:16:37.560Z
Learning: For the Bifrost MCP implementation, performance optimizations like caching tool discovery results should be deferred until after core functionality is complete. The author prefers to implement core features first and handle optimizations as follow-up work.
docs/features/integrations/README.md (4)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:89-119
Timestamp: 2025-06-10T11:00:02.875Z
Learning: In the Bifrost OpenAI integration (transports/bifrost-http/integrations/openai/types.go), the convertOpenAIContent function currently only handles the last image URL when multiple images are present in a content array. The user Pratham-Mishra04 has acknowledged this limitation and indicated it's part of a larger architectural issue that will be addressed comprehensively later, rather than with piecemeal fixes.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#82
File: tests/transports-integrations/tests/integrations/test_litellm.py:97-115
Timestamp: 2025-06-16T09:16:15.634Z
Learning: In the Bifrost integration tests, the user prefers tests to fail hard when API keys are missing rather than using @skip_if_no_api_key decorators for graceful skipping. This applies to LiteLLM tests that depend on OpenAI API keys.
docs/features/key-management.md (3)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/config/account.go:55-101
Timestamp: 2025-06-16T04:25:00.816Z
Learning: In the Bifrost test account implementation, the user prefers to let Bifrost itself handle missing API key errors rather than adding early validation in the GetKeysForProvider method.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/providers/bedrock.go:241-252
Timestamp: 2025-06-04T09:07:20.867Z
Learning: In the Bifrost codebase, when working with AWS Bedrock provider authentication, the preference is to let AWS handle access key validation naturally rather than adding preemptive checks for empty/blank access keys. This allows AWS to provide its own authentication error messages which can be more informative than custom validation errors.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:483-494
Timestamp: 2025-06-04T10:04:30.181Z
Learning: In the Anthropic provider (core/providers/anthropic.go), parallel tool calls support including the DisableParallelToolUse flag will be implemented in later commits as it's a relatively new feature that's not commonly used yet. The development approach prioritizes core functionality first.
docs/features/providers/anthropic.md (7)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: transports/config.example.json:36-42
Timestamp: 2025-06-16T03:55:30.933Z
Learning: Claude 3.7 Sonnet (claude-3-7-sonnet-20250219) is a valid Anthropic model released on February 24, 2025. It's their most intelligent model featuring hybrid reasoning capabilities and improved coding performance.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:483-494
Timestamp: 2025-06-04T09:36:27.956Z
Learning: In the Anthropic provider (core/providers/anthropic.go), the user has confirmed through practical experience that the tool_choice parameter should always use an object format with a "type" field (e.g., {"type": "auto"}, {"type": "tool", "name": "function_name"}), even though the official documentation examples sometimes show "auto" as a direct string. The current implementation correctly handles all tool choice types with the object format.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:483-494
Timestamp: 2025-06-04T10:04:30.181Z
Learning: In the Anthropic provider (core/providers/anthropic.go), parallel tool calls support including the DisableParallelToolUse flag will be implemented in later commits as it's a relatively new feature that's not commonly used yet. The development approach prioritizes core functionality first.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#65
File: transports/bifrost-http/integrations/anthropic/types.go:131-180
Timestamp: 2025-06-10T13:11:37.867Z
Learning: In Anthropic API integration for Bifrost, messages won't contain both image and tool_result content blocks in the same message, so defensive guards against multiple embedded message structs are unnecessary in the content processing loop.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:0-0
Timestamp: 2025-06-04T05:44:09.141Z
Learning: For the Anthropic provider in core/providers/anthropic.go, it's acceptable to pass potentially malformed messages with invalid roles because Anthropic's API will return suitable error responses for role issues, eliminating the need for additional validation logging.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:485-498
Timestamp: 2025-06-04T05:13:41.923Z
Learning: Anthropic's Claude API supports the following tool_choice parameter values: "auto" (default), "any" (force use of at least one tool), and {"type": "tool", "name": "tool_name"} (force use of specific tool). Anthropic does NOT support "none" as a tool_choice value - there's no way to disable tool usage once tools are provided in the request.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:485-498
Timestamp: 2025-06-04T05:13:41.923Z
Learning: Anthropic's Claude API supports the following tool_choice parameter values: "auto" (default - Claude decides whether to use tools), "none" (disables tool usage entirely), "any" (forces Claude to use at least one tool), and {"type": "tool", "name": "tool_name"} (forces use of a specific tool). All of these values are officially supported by Anthropic's API.
docs/architecture/concurrency.md (2)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:483-494
Timestamp: 2025-06-04T10:04:30.181Z
Learning: In the Anthropic provider (core/providers/anthropic.go), parallel tool calls support including the DisableParallelToolUse flag will be implemented in later commits as it's a relatively new feature that's not commonly used yet. The development approach prioritizes core functionality first.
docs/features/providers/azure.md (1)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:89-119
Timestamp: 2025-06-10T11:00:02.875Z
Learning: In the Bifrost OpenAI integration (transports/bifrost-http/integrations/openai/types.go), the convertOpenAIContent function currently only handles the last image URL when multiple images are present in a content array. The user Pratham-Mishra04 has acknowledged this limitation and indicated it's part of a larger architectural issue that will be addressed comprehensively later, rather than with piecemeal fixes.
docs/architecture/performance.md (5)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/mcp.go:696-711
Timestamp: 2025-06-18T20:16:37.560Z
Learning: For the Bifrost MCP implementation, performance optimizations like caching tool discovery results should be deferred until after core functionality is complete. The author prefers to implement core features first and handle optimizations as follow-up work.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:483-494
Timestamp: 2025-06-04T10:04:30.181Z
Learning: In the Anthropic provider (core/providers/anthropic.go), parallel tool calls support including the DisableParallelToolUse flag will be implemented in later commits as it's a relatively new feature that's not commonly used yet. The development approach prioritizes core functionality first.
docs/architecture/request-flow.md (5)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/router.go:0-0
Timestamp: 2025-06-09T14:03:34.227Z
Learning: In the Bifrost HTTP transport layer (transports/bifrost-http/integrations/), request validation like checking for empty messages should be handled by the provider rather than at the transport layer. The transport layer should forward requests to Bifrost core/providers for validation.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:89-119
Timestamp: 2025-06-10T11:00:02.875Z
Learning: In the Bifrost OpenAI integration (transports/bifrost-http/integrations/openai/types.go), the convertOpenAIContent function currently only handles the last image URL when multiple images are present in a content array. The user Pratham-Mishra04 has acknowledged this limitation and indicated it's part of a larger architectural issue that will be addressed comprehensively later, rather than with piecemeal fixes.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
docs/features/providers/README.md (11)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:483-494
Timestamp: 2025-06-04T10:04:30.181Z
Learning: In the Anthropic provider (core/providers/anthropic.go), parallel tool calls support including the DisableParallelToolUse flag will be implemented in later commits as it's a relatively new feature that's not commonly used yet. The development approach prioritizes core functionality first.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#85
File: core/providers/anthropic.go:150-156
Timestamp: 2025-06-15T16:07:53.140Z
Learning: In the Bifrost codebase, constructor functions are allowed to mutate input ProviderConfig objects in-place (e.g., setting default BaseURL values and trimming trailing slashes). This pattern is acceptable and doesn't need to be flagged as a code review issue.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/providers/bedrock.go:241-252
Timestamp: 2025-06-04T09:07:20.867Z
Learning: In the Bifrost codebase, when working with AWS Bedrock provider authentication, the preference is to let AWS handle access key validation naturally rather than adding preemptive checks for empty/blank access keys. This allows AWS to provide its own authentication error messages which can be more informative than custom validation errors.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/tests/e2e_tool_test.go:29-30
Timestamp: 2025-06-04T04:58:12.239Z
Learning: In the Bifrost project, environment variables should be used only for secrets (like API keys), not for general configuration. Test parameters like provider and model can be hardcoded at the start of test files for predictability and consistency.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/config/account.go:55-101
Timestamp: 2025-06-16T04:25:00.816Z
Learning: In the Bifrost test account implementation, the user prefers to let Bifrost itself handle missing API key errors rather than adding early validation in the GetKeysForProvider method.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:96-101
Timestamp: 2025-06-15T13:50:41.418Z
Learning: In the Bifrost project, when a provider doesn't support a specific operation (like text completion), the IsBifrostError flag should be set to false to mark it as a provider-level error rather than a Bifrost framework error. This is intentional design for unsupported operations.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/router.go:0-0
Timestamp: 2025-06-09T14:03:34.227Z
Learning: In the Bifrost HTTP transport layer (transports/bifrost-http/integrations/), request validation like checking for empty messages should be handled by the provider rather than at the transport layer. The transport layer should forward requests to Bifrost core/providers for validation.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:264-285
Timestamp: 2025-06-10T12:58:45.501Z
Learning: In the Bifrost OpenAI integration, tool calls should be allowed on any message role (not just assistant messages) and the downstream provider should handle validation. Users passing tool calls to non-assistant messages is considered deliberate behavior that should be preserved.
docs/features/mcp-integration.md (4)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#100
File: core/mcp.go:489-490
Timestamp: 2025-06-19T12:38:07.544Z
Learning: In the Bifrost MCP manager (core/mcp.go), the connectToMCPClient method is called during initialization/connection setup, not frequently during runtime. Logging operations like m.logger.Info inside critical sections in this context have negligible performance impact and don't require optimization for lock contention.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:264-285
Timestamp: 2025-06-10T12:58:45.501Z
Learning: In the Bifrost OpenAI integration, tool calls should be allowed on any message role (not just assistant messages) and the downstream provider should handle validation. Users passing tool calls to non-assistant messages is considered deliberate behavior that should be preserved.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/mcp.go:696-711
Timestamp: 2025-06-18T20:16:37.560Z
Learning: For the Bifrost MCP implementation, performance optimizations like caching tool discovery results should be deferred until after core functionality is complete. The author prefers to implement core features first and handle optimizations as follow-up work.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:483-494
Timestamp: 2025-06-04T10:04:30.181Z
Learning: In the Anthropic provider (core/providers/anthropic.go), parallel tool calls support including the DisableParallelToolUse flag will be implemented in later commits as it's a relatively new feature that's not commonly used yet. The development approach prioritizes core functionality first.
docs/features/logging.md (1)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/bifrost.go:823-845
Timestamp: 2025-06-18T15:15:51.323Z
Learning: In the Bifrost project, the team prioritizes maintaining consistent error handling patterns over exposing detailed error context. All errors should be wrapped in the standard `BifrostError` structure rather than creating specific error types or exposing richer error details like exit codes or stderr output.
docs/features/networking.md (2)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
docs/features/memory-management.md (1)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
docs/configuration/core-config.md (5)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#135
File: docs/core-package.md:105-116
Timestamp: 2025-06-27T17:07:39.420Z
Learning: In Go, when importing a package, the identifier used to access it is determined by the `package` declaration in the Go source files, not the directory name. For the Bifrost project, the core directory files declare `package bifrost`, so importing `"github.com/maximhq/bifrost/core"` automatically makes it accessible as `bifrost.Init`, `bifrost.Ptr`, etc., without needing an explicit alias.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/openai_test.go:1-2
Timestamp: 2025-06-16T04:29:53.409Z
Learning: In the Bifrost project, the user prefers to use `package main` for test files in the tests/core-providers directory rather than more descriptive package names like `coreproviders_test`.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/config/account.go:55-101
Timestamp: 2025-06-16T04:25:00.816Z
Learning: In the Bifrost test account implementation, the user prefers to let Bifrost itself handle missing API key errors rather than adding early validation in the GetKeysForProvider method.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/tests/e2e_tool_test.go:29-30
Timestamp: 2025-06-04T04:58:12.239Z
Learning: In the Bifrost project, environment variables should be used only for secrets (like API keys), not for general configuration. Test parameters like provider and model can be hardcoded at the start of test files for predictability and consistency.
docs/features/plugins.md (1)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#79
File: core/bifrost.go:94-103
Timestamp: 2025-06-14T04:06:58.240Z
Learning: In core/bifrost.go, the count parameter in RunPostHooks method is intentionally kept separate from p.executedPreHooks to support circuit breaker plugins that may need to trigger PostHooks for only a subset of executed plugins when detecting failure conditions mid-execution.
docs/architecture/design-decisions.md (11)
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: connyay
PR: maximhq/bifrost#92
File: core/providers/utils.go:60-64
Timestamp: 2025-06-17T14:04:21.104Z
Learning: The bifrost codebase uses string alias types (like `type ContextKey string`) for context keys consistently across multiple packages including plugins/maxim/main.go and transports/bifrost-http/tracking/plugin.go. This pattern should be maintained for consistency rather than switching to the canonical struct{} approach.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#89
File: transports/bifrost-http/integrations/genai/types.go:151-155
Timestamp: 2025-06-16T14:45:48.563Z
Learning: In transports/bifrost-http/integrations/genai/types.go, when SystemInstruction has an empty role, the user prefers to let the downstream provider (Google GenAI) handle validation and return errors, rather than implementing validation in the bifrost layer. This represents a design preference for delegating validation to the appropriate service rather than duplicating validation logic in the proxy layer.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/bifrost.go:823-845
Timestamp: 2025-06-18T15:15:51.323Z
Learning: In the Bifrost project, the team prioritizes maintaining consistent error handling patterns over exposing detailed error context. All errors should be wrapped in the standard `BifrostError` structure rather than creating specific error types or exposing richer error details like exit codes or stderr output.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:96-101
Timestamp: 2025-06-15T13:50:41.418Z
Learning: In the Bifrost project, when a provider doesn't support a specific operation (like text completion), the IsBifrostError flag should be set to false to mark it as a provider-level error rather than a Bifrost framework error. This is intentional design for unsupported operations.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#85
File: core/providers/anthropic.go:150-156
Timestamp: 2025-06-15T16:07:53.140Z
Learning: In the Bifrost codebase, constructor functions are allowed to mutate input ProviderConfig objects in-place (e.g., setting default BaseURL values and trimming trailing slashes). This pattern is acceptable and doesn't need to be flagged as a code review issue.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#65
File: transports/bifrost-http/integrations/anthropic/types.go:140-146
Timestamp: 2025-06-10T13:51:52.859Z
Learning: In Bifrost core v1.0.9, ImageContent.Type was a pointer type (*string accessed via bifrost.Ptr), but in v1.0.10 it was changed to a value type (ImageContentType). When reviewing code, check the core version being used to determine the correct assignment pattern.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/mcp.go:696-711
Timestamp: 2025-06-18T20:16:37.560Z
Learning: For the Bifrost MCP implementation, performance optimizations like caching tool discovery results should be deferred until after core functionality is complete. The author prefers to implement core features first and handle optimizations as follow-up work.
🪛 LanguageTool
docs/features/providers.md
[uncategorized] ~3-~3: Possible missing comma found.
Context: ...ent interface. Switch between providers seamlessly or configure automatic fallbacks for ma...
(AI_HYDRA_LEO_MISSING_COMMA)
docs/configuration/README.md
[uncategorized] ~59-~59: You might be missing the article “a” here.
Context: ...P Setup 1. Create configuration file (config.json): ```json { "p...
(AI_EN_LECTOR_MISSING_DETERMINER_A)
[grammar] ~242-~242: A determiner may be missing.
Context: ...guration:** - Port: 9090 (from flag, highest priority) - Log Level: debug (from fl...
(THE_SUPERLATIVE)
docs/contributing/README.md
[typographical] ~24-~24: If specifying a range, consider using an en dash instead of a hyphen.
Context: ...* | Any | 5-15 minutes | | **[📝 Documentation](doc...
(HYPHEN_TO_EN)
[typographical] ~25-~25: If specifying a range, consider using an en dash instead of a hyphen.
Context: ...md)** | Any | 15-60 minutes | | **[🧪 Testing](testing.md...
(HYPHEN_TO_EN)
[typographical] ~26-~26: If specifying a range, consider using an en dash instead of a hyphen.
Context: ... | Intermediate | 30-120 minutes | | **[💻 Development](develop...
(HYPHEN_TO_EN)
[typographical] ~27-~27: If specifying a range, consider using an en dash instead of a hyphen.
Context: ...* | Advanced | 2-8 hours | | **[🔌 Integrations](../...
(HYPHEN_TO_EN)
[typographical] ~28-~28: If specifying a range, consider using an en dash instead of a hyphen.
Context: ...egrations/README.md)** | Advanced | 4-16 hours | ### Quick Start 1. **For...
(HYPHEN_TO_EN)
[duplication] ~481-~481: Possible typo: you repeated a word.
Context: ...Approval*: Two approvals required for merge 5. Merge: Squash and merge to main branch ---...
(ENGLISH_WORD_REPEAT_RULE)
docs/benchmarks.md
[uncategorized] ~68-~68: Do not mix variants of the same word (‘marshaling’ and ‘marshalling’) within a single text.
Context: ...rrency management - 58% faster JSON marshaling leverages better CPU throughput --- #...
(EN_EXACT_COHERENCY_RULE)
docs/README.md
[uncategorized] ~23-~23: Possible missing comma found.
Context: ...### 🎯 Core Features Essential Bifrost capabilities with examples for both Go package and H...
(AI_HYDRA_LEO_MISSING_COMMA)
docs/quick-start/README.md
[style] ~31-~31: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...refer REST API integration patterns - ✅ Want to scale AI requests independently ### 🔄...
(REP_WANT_TO_VB)
[style] ~38-~38: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...mediate fallback and load balancing - ✅ Want to test Bifrost without changing your app ...
(REP_WANT_TO_VB)
docs/guides/troubleshooting.md
[uncategorized] ~245-~245: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...ponse time: 1.234s ```
⏱️ R...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[duplication] ~252-~252: Possible typo: you repeated a word.
Context: ...g>
Symptoms: - HTTP 429 errors - Context: ...g>
rate_limit_exceeded errors - Slow response times Solutions: ...
(ENGLISH_WORD_REPEAT_RULE)
[uncategorized] ~623-~623: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...onfiguration 2. Error messages with full stack traces 3. Debug logs (with sensitiv...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
README.md
[uncategorized] ~212-~212: Possible missing comma found.
Context: ...% request success rate on both instance types even at 5 k RPS. - **Tiny Total Overhea...
(AI_HYDRA_LEO_MISSING_COMMA)
docs/guides/faq.md
[uncategorized] ~372-~372: You might be missing the article “an” here.
Context: ...? Troubleshooting ### Why am I getting "account is required" error? You need to...
(AI_EN_LECTOR_MISSING_DETERMINER_AN)
docs/features/fallbacks.md
[uncategorized] ~113-~113: A determiner appears to be missing. Consider inserting it.
Context: ...net-20240229" } ] }' **Response shows which provider was used:** js...
(AI_EN_LECTOR_MISSING_DETERMINER)
[grammar] ~503-~503: A determiner may be missing.
Context: ... ``` 2. Smart Ordering - Put fastest providers first - Use geographic pro...
(THE_SUPERLATIVE)
[uncategorized] ~503-~503: It seems likely that a singular genitive (’s) apostrophe is missing.
Context: ...2. Smart Ordering - Put fastest providers first - Use geographic proximity ...
(AI_HYDRA_LEO_APOSTROPHE_S_XS)
docs/quick-start/feature-comparison.md
[uncategorized] ~215-~215: You might be missing the article “the” here.
Context: ...trategy:** 1. Deploy Bifrost alongside existing system 2. Route percentage of traffic t...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[style] ~450-~450: This phrase is redundant (‘I’ stands for ‘interface’). Use simply “API”.
Context: ...us tech stacks** | Standardized REST API interface | | **Scaling AI requests sepa...
(ACRONYM_TAUTOLOGY)
docs/architecture/system-overview.md
[grammar] ~100-~100: It appears that a hyphen is missing.
Context: ..., future gRPC - 🎣 Plugin Pipeline: Pre/post-hooks for custom logic - 💾 Memory Pools:...
(PRE_AND_POST_NN)
[uncategorized] ~175-~175: This expression is usually spelled with a hyphen.
Context: ...1k-5k RPS) - InitialPoolSize: 20000 - Ultra high throughput (10k+ RPS) ### Provider Wor...
(ULTRA_HYPHEN)
docs/features/integrations/README.md
[uncategorized] ~76-~76: The grammatical number of this noun doesn’t look right. Consider replacing it.
Context: ...low 1. Your app makes standard API call (e.g., OpenAI format) 2. **Integration ...
(AI_EN_LECTOR_REPLACEMENT_NOUN_NUMBER)
[uncategorized] ~165-~165: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...ulti-provider routing - Cost tracking - Rate limiting - Model aliasing --- ## 🔧 Configurat...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[grammar] ~302-~302: A determiner may be missing.
Context: ...ion - Multi-provider routing - Use cheapest available model - **Automatic fallbacks...
(THE_SUPERLATIVE)
docs/features/key-management.md
[typographical] ~404-~404: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ...``` Selection ranges: - Key 1: 0.0 - 0.6 (60% chance) - Key 2: 0.6 - 0.9 (30%...
(DASH_RULE)
[typographical] ~405-~405: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ...y 1: 0.0 - 0.6 (60% chance) - Key 2: 0.6 - 0.9 (30% chance) - Key 3: 0.9 - 1.0 (10%...
(DASH_RULE)
[typographical] ~406-~406: If you want to indicate numerical ranges or time ranges, consider using an en dash.
Context: ...y 2: 0.6 - 0.9 (30% chance) - Key 3: 0.9 - 1.0 (10% chance) ### Fallback Behavior ...
(DASH_RULE)
[uncategorized] ~415-~415: Possible missing preposition found.
Context: ...e**, proceed to fallback providers 4. Retry failed keys after backoff period ---...
(AI_HYDRA_LEO_MISSING_TO)
[uncategorized] ~501-~501: You might be missing the article “a” here.
Context: ... 1. Zero-Downtime Rotation: - Add new key with small weight - Gradually incre...
(AI_EN_LECTOR_MISSING_DETERMINER_A)
[uncategorized] ~501-~501: You might be missing the article “a” here.
Context: ...owntime Rotation:** - Add new key with small weight - Gradually increase new key wei...
(AI_EN_LECTOR_MISSING_DETERMINER_A)
[style] ~503-~503: This adverb was used twice in the sentence. Consider removing one of them or replacing them with a synonym.
Context: ...t - Gradually increase new key weight - Gradually decrease old key weight - Remove old ke...
(ADVERB_REPETITION_PREMIUM)
docs/architecture/request-flow.md
[uncategorized] ~268-~268: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...lures - Rate Limit Errors: Provider rate limiting - Authentication Errors: Invalid AP...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[grammar] ~304-~304: It appears that hyphens are missing.
Context: ...ugin Pipeline** | < 5ms | Pre/post hook execution | | **Pool Operati...
(PRE_AND_POST_NN)
docs/features/providers/README.md
[uncategorized] ~253-~253: You might be missing the article “the” here.
Context: ...ement - Environment Variables: Use env. prefix for sensitive values - **Ke...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
docs/features/networking.md
[grammar] ~15-~15: You’ve repeated a verb. Did you mean to only write one of them?
Context: ...onment-based-proxy) - ⏱️ Timeouts & Retries - Retry Configuration ...
(REPEATED_VERBS)
[uncategorized] ~253-~253: “where” seems less likely than “were”.
Context: ...TP/2 Support**: Multiplexed connections where supported - ✅ Keep-Alive: Persisten...
(AI_HYDRA_LEO_CPT_WHERE_WERE)
docs/features/memory-management.md
[uncategorized] ~3-~3: You might be missing the article “a” here.
Context: ...rrency to deliver high performance with minimal memory footprint. ## 📑 Table of Conte...
(AI_EN_LECTOR_MISSING_DETERMINER_A)
docs/features/plugins.md
[uncategorized] ~203-~203: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...tails> --- ## 🎨 Plugin Examples ### Rate Limiting Plugin
🔧 G...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[uncategorized] ~613-~613: Possible missing preposition found.
Context: ...ks get corresponding PostHook calls - Reverse Order: PostHooks execute in reverse o...
(AI_HYDRA_LEO_MISSING_IN)
Context: ...ks get corresponding PostHook calls - Reverse Order: PostHooks execute in reverse o...
docs/architecture/design-decisions.md
[grammar] ~264-~264: It appears that hyphens are missing.
Context: ...# 3. Plugin Architecture Decision: Pre/Post hook system with short-circuit capability. ...
(PRE_AND_POST_NN)
docs/features/observability.md
[uncategorized] ~816-~816: You might be missing the article “the” here.
Context: ...Request Flow: Track request through entire pipeline - ⏱️ Stage Timing: Identif...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
🪛 markdownlint-cli2 (0.17.2)
docs/features/providers.md
22-22: Inline HTML
Element: details
(MD033, no-inline-html)
23-23: Inline HTML
Element: summary
(MD033, no-inline-html)
23-23: Inline HTML
Element: strong
(MD033, no-inline-html)
71-71: Inline HTML
Element: details
(MD033, no-inline-html)
72-72: Inline HTML
Element: summary
(MD033, no-inline-html)
72-72: Inline HTML
Element: strong
(MD033, no-inline-html)
docs/configuration/README.md
21-21: Inline HTML
Element: details
(MD033, no-inline-html)
22-22: Inline HTML
Element: summary
(MD033, no-inline-html)
22-22: Inline HTML
Element: strong
(MD033, no-inline-html)
56-56: Inline HTML
Element: details
(MD033, no-inline-html)
57-57: Inline HTML
Element: summary
(MD033, no-inline-html)
57-57: Inline HTML
Element: strong
(MD033, no-inline-html)
211-211: Inline HTML
Element: details
(MD033, no-inline-html)
212-212: Inline HTML
Element: summary
(MD033, no-inline-html)
212-212: Inline HTML
Element: strong
(MD033, no-inline-html)
248-248: Inline HTML
Element: details
(MD033, no-inline-html)
249-249: Inline HTML
Element: summary
(MD033, no-inline-html)
249-249: Inline HTML
Element: strong
(MD033, no-inline-html)
285-285: Inline HTML
Element: details
(MD033, no-inline-html)
286-286: Inline HTML
Element: summary
(MD033, no-inline-html)
286-286: Inline HTML
Element: strong
(MD033, no-inline-html)
341-341: Inline HTML
Element: details
(MD033, no-inline-html)
342-342: Inline HTML
Element: summary
(MD033, no-inline-html)
342-342: Inline HTML
Element: strong
(MD033, no-inline-html)
426-426: Inline HTML
Element: details
(MD033, no-inline-html)
427-427: Inline HTML
Element: summary
(MD033, no-inline-html)
427-427: Inline HTML
Element: strong
(MD033, no-inline-html)
487-487: Inline HTML
Element: details
(MD033, no-inline-html)
488-488: Inline HTML
Element: summary
(MD033, no-inline-html)
488-488: Inline HTML
Element: strong
(MD033, no-inline-html)
docs/quick-start/go-package.md
74-74: Inline HTML
Element: details
(MD033, no-inline-html)
75-75: Inline HTML
Element: summary
(MD033, no-inline-html)
75-75: Inline HTML
Element: strong
(MD033, no-inline-html)
110-110: Inline HTML
Element: details
(MD033, no-inline-html)
111-111: Inline HTML
Element: summary
(MD033, no-inline-html)
111-111: Inline HTML
Element: strong
(MD033, no-inline-html)
119-119: Inline HTML
Element: details
(MD033, no-inline-html)
120-120: Inline HTML
Element: summary
(MD033, no-inline-html)
120-120: Inline HTML
Element: strong
(MD033, no-inline-html)
docs/quick-start/http-transport.md
80-80: Inline HTML
Element: details
(MD033, no-inline-html)
81-81: Inline HTML
Element: summary
(MD033, no-inline-html)
81-81: Inline HTML
Element: strong
(MD033, no-inline-html)
docs/benchmarks.md
24-24: Inline HTML
Element: br
(MD033, no-inline-html)
25-25: Inline HTML
Element: br
(MD033, no-inline-html)
docs/guides/troubleshooting.md
22-22: Inline HTML
Element: details
(MD033, no-inline-html)
23-23: Inline HTML
Element: summary
(MD033, no-inline-html)
23-23: Inline HTML
Element: strong
(MD033, no-inline-html)
60-60: Inline HTML
Element: details
(MD033, no-inline-html)
61-61: Inline HTML
Element: summary
(MD033, no-inline-html)
61-61: Inline HTML
Element: strong
(MD033, no-inline-html)
97-97: Inline HTML
Element: details
(MD033, no-inline-html)
98-98: Inline HTML
Element: summary
(MD033, no-inline-html)
98-98: Inline HTML
Element: strong
(MD033, no-inline-html)
136-136: Inline HTML
Element: details
(MD033, no-inline-html)
137-137: Inline HTML
Element: summary
(MD033, no-inline-html)
137-137: Inline HTML
Element: strong
(MD033, no-inline-html)
201-201: Inline HTML
Element: details
(MD033, no-inline-html)
202-202: Inline HTML
Element: summary
(MD033, no-inline-html)
202-202: Inline HTML
Element: strong
(MD033, no-inline-html)
234-234: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
247-247: Inline HTML
Element: details
(MD033, no-inline-html)
248-248: Inline HTML
Element: summary
(MD033, no-inline-html)
248-248: Inline HTML
Element: strong
(MD033, no-inline-html)
297-297: Inline HTML
Element: details
(MD033, no-inline-html)
298-298: Inline HTML
Element: summary
(MD033, no-inline-html)
298-298: Inline HTML
Element: strong
(MD033, no-inline-html)
375-375: Inline HTML
Element: details
(MD033, no-inline-html)
376-376: Inline HTML
Element: summary
(MD033, no-inline-html)
376-376: Inline HTML
Element: strong
(MD033, no-inline-html)
419-419: Inline HTML
Element: details
(MD033, no-inline-html)
420-420: Inline HTML
Element: summary
(MD033, no-inline-html)
420-420: Inline HTML
Element: strong
(MD033, no-inline-html)
467-467: Inline HTML
Element: details
(MD033, no-inline-html)
468-468: Inline HTML
Element: summary
(MD033, no-inline-html)
468-468: Inline HTML
Element: strong
(MD033, no-inline-html)
505-505: Inline HTML
Element: details
(MD033, no-inline-html)
506-506: Inline HTML
Element: summary
(MD033, no-inline-html)
506-506: Inline HTML
Element: strong
(MD033, no-inline-html)
540-540: Inline HTML
Element: details
(MD033, no-inline-html)
541-541: Inline HTML
Element: summary
(MD033, no-inline-html)
541-541: Inline HTML
Element: strong
(MD033, no-inline-html)
570-570: Inline HTML
Element: details
(MD033, no-inline-html)
571-571: Inline HTML
Element: summary
(MD033, no-inline-html)
571-571: Inline HTML
Element: strong
(MD033, no-inline-html)
docs/guides/faq.md
57-57: Inline HTML
Element: details
(MD033, no-inline-html)
58-58: Inline HTML
Element: summary
(MD033, no-inline-html)
58-58: Inline HTML
Element: strong
(MD033, no-inline-html)
199-199: Inline HTML
Element: details
(MD033, no-inline-html)
200-200: Inline HTML
Element: summary
(MD033, no-inline-html)
200-200: Inline HTML
Element: strong
(MD033, no-inline-html)
311-311: Inline HTML
Element: details
(MD033, no-inline-html)
312-312: Inline HTML
Element: summary
(MD033, no-inline-html)
312-312: Inline HTML
Element: strong
(MD033, no-inline-html)
docs/features/fallbacks.md
61-61: Inline HTML
Element: details
(MD033, no-inline-html)
62-62: Inline HTML
Element: summary
(MD033, no-inline-html)
62-62: Inline HTML
Element: strong
(MD033, no-inline-html)
94-94: Inline HTML
Element: details
(MD033, no-inline-html)
95-95: Inline HTML
Element: summary
(MD033, no-inline-html)
95-95: Inline HTML
Element: strong
(MD033, no-inline-html)
131-131: Inline HTML
Element: details
(MD033, no-inline-html)
132-132: Inline HTML
Element: summary
(MD033, no-inline-html)
132-132: Inline HTML
Element: strong
(MD033, no-inline-html)
160-160: Inline HTML
Element: details
(MD033, no-inline-html)
161-161: Inline HTML
Element: summary
(MD033, no-inline-html)
161-161: Inline HTML
Element: strong
(MD033, no-inline-html)
183-183: Inline HTML
Element: details
(MD033, no-inline-html)
184-184: Inline HTML
Element: summary
(MD033, no-inline-html)
184-184: Inline HTML
Element: strong
(MD033, no-inline-html)
209-209: Inline HTML
Element: details
(MD033, no-inline-html)
210-210: Inline HTML
Element: summary
(MD033, no-inline-html)
210-210: Inline HTML
Element: strong
(MD033, no-inline-html)
233-233: Inline HTML
Element: details
(MD033, no-inline-html)
234-234: Inline HTML
Element: summary
(MD033, no-inline-html)
234-234: Inline HTML
Element: strong
(MD033, no-inline-html)
260-260: Inline HTML
Element: details
(MD033, no-inline-html)
261-261: Inline HTML
Element: summary
(MD033, no-inline-html)
261-261: Inline HTML
Element: strong
(MD033, no-inline-html)
285-285: Inline HTML
Element: details
(MD033, no-inline-html)
286-286: Inline HTML
Element: summary
(MD033, no-inline-html)
286-286: Inline HTML
Element: strong
(MD033, no-inline-html)
306-306: Inline HTML
Element: details
(MD033, no-inline-html)
307-307: Inline HTML
Element: summary
(MD033, no-inline-html)
307-307: Inline HTML
Element: strong
(MD033, no-inline-html)
373-373: Inline HTML
Element: details
(MD033, no-inline-html)
374-374: Inline HTML
Element: summary
(MD033, no-inline-html)
374-374: Inline HTML
Element: strong
(MD033, no-inline-html)
403-403: Inline HTML
Element: details
(MD033, no-inline-html)
404-404: Inline HTML
Element: summary
(MD033, no-inline-html)
404-404: Inline HTML
Element: strong
(MD033, no-inline-html)
docs/quick-start/feature-comparison.md
71-71: Inline HTML
Element: details
(MD033, no-inline-html)
72-72: Inline HTML
Element: summary
(MD033, no-inline-html)
72-72: Inline HTML
Element: strong
(MD033, no-inline-html)
94-94: Inline HTML
Element: details
(MD033, no-inline-html)
95-95: Inline HTML
Element: summary
(MD033, no-inline-html)
95-95: Inline HTML
Element: strong
(MD033, no-inline-html)
120-120: Inline HTML
Element: details
(MD033, no-inline-html)
121-121: Inline HTML
Element: summary
(MD033, no-inline-html)
121-121: Inline HTML
Element: strong
(MD033, no-inline-html)
149-149: Inline HTML
Element: details
(MD033, no-inline-html)
150-150: Inline HTML
Element: summary
(MD033, no-inline-html)
150-150: Inline HTML
Element: strong
(MD033, no-inline-html)
180-180: Inline HTML
Element: details
(MD033, no-inline-html)
181-181: Inline HTML
Element: summary
(MD033, no-inline-html)
181-181: Inline HTML
Element: strong
(MD033, no-inline-html)
203-203: Inline HTML
Element: details
(MD033, no-inline-html)
204-204: Inline HTML
Element: summary
(MD033, no-inline-html)
204-204: Inline HTML
Element: strong
(MD033, no-inline-html)
356-356: Inline HTML
Element: details
(MD033, no-inline-html)
357-357: Inline HTML
Element: summary
(MD033, no-inline-html)
357-357: Inline HTML
Element: strong
(MD033, no-inline-html)
369-369: Inline HTML
Element: details
(MD033, no-inline-html)
370-370: Inline HTML
Element: summary
(MD033, no-inline-html)
370-370: Inline HTML
Element: strong
(MD033, no-inline-html)
380-380: Inline HTML
Element: details
(MD033, no-inline-html)
381-381: Inline HTML
Element: summary
(MD033, no-inline-html)
381-381: Inline HTML
Element: strong
(MD033, no-inline-html)
415-415: Multiple top-level headings in the same document
null
(MD025, single-title, single-h1)
434-434: Trailing punctuation in heading
Punctuation: ':'
(MD026, no-trailing-punctuation)
444-444: Trailing punctuation in heading
Punctuation: ':'
(MD026, no-trailing-punctuation)
454-454: Trailing punctuation in heading
Punctuation: ':'
(MD026, no-trailing-punctuation)
docs/features/providers/anthropic.md
17-17: Inline HTML
Element: details
(MD033, no-inline-html)
18-18: Inline HTML
Element: summary
(MD033, no-inline-html)
18-18: Inline HTML
Element: strong
(MD033, no-inline-html)
91-91: Inline HTML
Element: details
(MD033, no-inline-html)
92-92: Inline HTML
Element: summary
(MD033, no-inline-html)
92-92: Inline HTML
Element: strong
(MD033, no-inline-html)
140-140: Multiple headings with the same content
null
(MD024, no-duplicate-heading)
180-180: Inline HTML
Element: details
(MD033, no-inline-html)
181-181: Inline HTML
Element: summary
(MD033, no-inline-html)
181-181: Inline HTML
Element: strong
(MD033, no-inline-html)
205-205: Inline HTML
Element: details
(MD033, no-inline-html)
206-206: Inline HTML
Element: summary
(MD033, no-inline-html)
206-206: Inline HTML
Element: strong
(MD033, no-inline-html)
236-236: Inline HTML
Element: details
(MD033, no-inline-html)
237-237: Inline HTML
Element: summary
(MD033, no-inline-html)
237-237: Inline HTML
Element: strong
(MD033, no-inline-html)
254-254: Inline HTML
Element: details
(MD033, no-inline-html)
255-255: Inline HTML
Element: summary
(MD033, no-inline-html)
255-255: Inline HTML
Element: strong
(MD033, no-inline-html)
279-279: Inline HTML
Element: details
(MD033, no-inline-html)
280-280: Inline HTML
Element: summary
(MD033, no-inline-html)
280-280: Inline HTML
Element: strong
(MD033, no-inline-html)
309-309: Inline HTML
Element: details
(MD033, no-inline-html)
310-310: Inline HTML
Element: summary
(MD033, no-inline-html)
310-310: Inline HTML
Element: strong
(MD033, no-inline-html)
334-334: Inline HTML
Element: details
(MD033, no-inline-html)
335-335: Inline HTML
Element: summary
(MD033, no-inline-html)
335-335: Inline HTML
Element: strong
(MD033, no-inline-html)
377-377: Inline HTML
Element: details
(MD033, no-inline-html)
378-378: Inline HTML
Element: summary
(MD033, no-inline-html)
378-378: Inline HTML
Element: strong
(MD033, no-inline-html)
docs/architecture/request-flow.md
48-48: Inline HTML
Element: details
(MD033, no-inline-html)
49-49: Inline HTML
Element: summary
(MD033, no-inline-html)
49-49: Inline HTML
Element: strong
(MD033, no-inline-html)
77-77: Inline HTML
Element: details
(MD033, no-inline-html)
78-78: Inline HTML
Element: summary
(MD033, no-inline-html)
78-78: Inline HTML
Element: strong
(MD033, no-inline-html)
docs/features/providers/README.md
22-22: Inline HTML
Element: details
(MD033, no-inline-html)
23-23: Inline HTML
Element: summary
(MD033, no-inline-html)
23-23: Inline HTML
Element: strong
(MD033, no-inline-html)
87-87: Inline HTML
Element: details
(MD033, no-inline-html)
88-88: Inline HTML
Element: summary
(MD033, no-inline-html)
88-88: Inline HTML
Element: strong
(MD033, no-inline-html)
187-187: Inline HTML
Element: details
(MD033, no-inline-html)
188-188: Inline HTML
Element: summary
(MD033, no-inline-html)
188-188: Inline HTML
Element: strong
(MD033, no-inline-html)
216-216: Inline HTML
Element: details
(MD033, no-inline-html)
217-217: Inline HTML
Element: summary
(MD033, no-inline-html)
217-217: Inline HTML
Element: strong
(MD033, no-inline-html)
docs/features/logging.md
28-28: Inline HTML
Element: details
(MD033, no-inline-html)
29-29: Inline HTML
Element: summary
(MD033, no-inline-html)
29-29: Inline HTML
Element: strong
(MD033, no-inline-html)
74-74: Inline HTML
Element: details
(MD033, no-inline-html)
75-75: Inline HTML
Element: summary
(MD033, no-inline-html)
75-75: Inline HTML
Element: strong
(MD033, no-inline-html)
143-143: Inline HTML
Element: details
(MD033, no-inline-html)
144-144: Inline HTML
Element: summary
(MD033, no-inline-html)
144-144: Inline HTML
Element: strong
(MD033, no-inline-html)
185-185: Inline HTML
Element: details
(MD033, no-inline-html)
186-186: Inline HTML
Element: summary
(MD033, no-inline-html)
186-186: Inline HTML
Element: strong
(MD033, no-inline-html)
219-219: Inline HTML
Element: details
(MD033, no-inline-html)
220-220: Inline HTML
Element: summary
(MD033, no-inline-html)
220-220: Inline HTML
Element: strong
(MD033, no-inline-html)
317-317: Inline HTML
Element: details
(MD033, no-inline-html)
318-318: Inline HTML
Element: summary
(MD033, no-inline-html)
318-318: Inline HTML
Element: strong
(MD033, no-inline-html)
387-387: Inline HTML
Element: details
(MD033, no-inline-html)
388-388: Inline HTML
Element: summary
(MD033, no-inline-html)
388-388: Inline HTML
Element: strong
(MD033, no-inline-html)
462-462: Inline HTML
Element: details
(MD033, no-inline-html)
463-463: Inline HTML
Element: summary
(MD033, no-inline-html)
463-463: Inline HTML
Element: strong
(MD033, no-inline-html)
532-532: Inline HTML
Element: details
(MD033, no-inline-html)
533-533: Inline HTML
Element: summary
(MD033, no-inline-html)
533-533: Inline HTML
Element: strong
(MD033, no-inline-html)
571-571: Inline HTML
Element: details
(MD033, no-inline-html)
572-572: Inline HTML
Element: summary
(MD033, no-inline-html)
572-572: Inline HTML
Element: strong
(MD033, no-inline-html)
615-615: Inline HTML
Element: details
(MD033, no-inline-html)
616-616: Inline HTML
Element: summary
(MD033, no-inline-html)
616-616: Inline HTML
Element: strong
(MD033, no-inline-html)
660-660: Inline HTML
Element: details
(MD033, no-inline-html)
661-661: Inline HTML
Element: summary
(MD033, no-inline-html)
661-661: Inline HTML
Element: strong
(MD033, no-inline-html)
710-710: Inline HTML
Element: details
(MD033, no-inline-html)
711-711: Inline HTML
Element: summary
(MD033, no-inline-html)
711-711: Inline HTML
Element: strong
(MD033, no-inline-html)
748-748: Inline HTML
Element: details
(MD033, no-inline-html)
749-749: Inline HTML
Element: summary
(MD033, no-inline-html)
749-749: Inline HTML
Element: strong
(MD033, no-inline-html)
docs/features/networking.md
26-26: Inline HTML
Element: details
(MD033, no-inline-html)
27-27: Inline HTML
Element: summary
(MD033, no-inline-html)
27-27: Inline HTML
Element: strong
(MD033, no-inline-html)
65-65: Inline HTML
Element: details
(MD033, no-inline-html)
66-66: Inline HTML
Element: summary
(MD033, no-inline-html)
66-66: Inline HTML
Element: strong
(MD033, no-inline-html)
103-103: Inline HTML
Element: details
(MD033, no-inline-html)
104-104: Inline HTML
Element: summary
(MD033, no-inline-html)
104-104: Inline HTML
Element: strong
(MD033, no-inline-html)
121-121: Inline HTML
Element: details
(MD033, no-inline-html)
122-122: Inline HTML
Element: summary
(MD033, no-inline-html)
122-122: Inline HTML
Element: strong
(MD033, no-inline-html)
143-143: Inline HTML
Element: details
(MD033, no-inline-html)
144-144: Inline HTML
Element: summary
(MD033, no-inline-html)
144-144: Inline HTML
Element: strong
(MD033, no-inline-html)
163-163: Inline HTML
Element: details
(MD033, no-inline-html)
164-164: Inline HTML
Element: summary
(MD033, no-inline-html)
164-164: Inline HTML
Element: strong
(MD033, no-inline-html)
193-193: Inline HTML
Element: details
(MD033, no-inline-html)
194-194: Inline HTML
Element: summary
(MD033, no-inline-html)
194-194: Inline HTML
Element: strong
(MD033, no-inline-html)
227-227: Inline HTML
Element: details
(MD033, no-inline-html)
228-228: Inline HTML
Element: summary
(MD033, no-inline-html)
228-228: Inline HTML
Element: strong
(MD033, no-inline-html)
docs/features/plugins.md
23-23: Inline HTML
Element: details
(MD033, no-inline-html)
24-24: Inline HTML
Element: summary
(MD033, no-inline-html)
24-24: Inline HTML
Element: strong
(MD033, no-inline-html)
77-77: Inline HTML
Element: details
(MD033, no-inline-html)
78-78: Inline HTML
Element: summary
(MD033, no-inline-html)
78-78: Inline HTML
Element: strong
(MD033, no-inline-html)
162-162: Inline HTML
Element: details
(MD033, no-inline-html)
163-163: Inline HTML
Element: summary
(MD033, no-inline-html)
163-163: Inline HTML
Element: strong
(MD033, no-inline-html)
205-205: Inline HTML
Element: details
(MD033, no-inline-html)
206-206: Inline HTML
Element: summary
(MD033, no-inline-html)
206-206: Inline HTML
Element: strong
(MD033, no-inline-html)
314-314: Inline HTML
Element: details
(MD033, no-inline-html)
315-315: Inline HTML
Element: summary
(MD033, no-inline-html)
315-315: Inline HTML
Element: strong
(MD033, no-inline-html)
439-439: Inline HTML
Element: details
(MD033, no-inline-html)
440-440: Inline HTML
Element: summary
(MD033, no-inline-html)
440-440: Inline HTML
Element: strong
(MD033, no-inline-html)
550-550: Inline HTML
Element: details
(MD033, no-inline-html)
551-551: Inline HTML
Element: summary
(MD033, no-inline-html)
551-551: Inline HTML
Element: strong
(MD033, no-inline-html)
585-585: Inline HTML
Element: details
(MD033, no-inline-html)
586-586: Inline HTML
Element: summary
(MD033, no-inline-html)
586-586: Inline HTML
Element: strong
(MD033, no-inline-html)
619-619: Inline HTML
Element: details
(MD033, no-inline-html)
620-620: Inline HTML
Element: summary
(MD033, no-inline-html)
620-620: Inline HTML
Element: strong
(MD033, no-inline-html)
657-657: Inline HTML
Element: details
(MD033, no-inline-html)
658-658: Inline HTML
Element: summary
(MD033, no-inline-html)
658-658: Inline HTML
Element: strong
(MD033, no-inline-html)
706-706: Inline HTML
Element: details
(MD033, no-inline-html)
707-707: Inline HTML
Element: summary
(MD033, no-inline-html)
707-707: Inline HTML
Element: strong
(MD033, no-inline-html)
764-764: Inline HTML
Element: details
(MD033, no-inline-html)
765-765: Inline HTML
Element: summary
(MD033, no-inline-html)
765-765: Inline HTML
Element: strong
(MD033, no-inline-html)
860-860: Inline HTML
Element: details
(MD033, no-inline-html)
861-861: Inline HTML
Element: summary
(MD033, no-inline-html)
861-861: Inline HTML
Element: strong
(MD033, no-inline-html)
996-996: Inline HTML
Element: details
(MD033, no-inline-html)
997-997: Inline HTML
Element: summary
(MD033, no-inline-html)
997-997: Inline HTML
Element: strong
(MD033, no-inline-html)
1068-1068: Inline HTML
Element: details
(MD033, no-inline-html)
1069-1069: Inline HTML
Element: summary
(MD033, no-inline-html)
1069-1069: Inline HTML
Element: strong
(MD033, no-inline-html)
🔇 Additional comments (24)
core/schemas/bifrost.go (1)
429-429: LGTM! Good architectural decision to internalize fallback control.Making
AllowFallbacksinternal-only prevents external JSON exposure of internal fallback control flags, which aligns with keeping plugin-controlled behavior separate from the public API surface.docs/guides/README.md (1)
1-47: Excellent user guide structure and organization.This provides a clear entry point for users seeking help, with logical organization from specific guides to navigation aids to community support. The format is consistent and user-friendly.
docs/quick-start/README.md (1)
1-117: Comprehensive and well-structured quick start guide.The guide effectively helps users choose the appropriate integration method with clear comparisons, setup instructions, and next steps. The format is consistent with the broader documentation ecosystem.
docs/contributing/README.md (2)
1-587: Excellent comprehensive contributing guide.This guide covers all essential aspects of contributing to Bifrost with clear examples, proper structure, and helpful templates. It will significantly improve the contributor experience.
481-481: Fix word repetition in merge process.Remove the duplicate word "approvals" in the approval step.
-4. **Approval**: Two approvals required for merge +4. **Approval**: Two approvals required for mergeLikely an incorrect or invalid review comment.
docs/quick-start/http-transport.md (1)
1-242: Comprehensive and practical HTTP transport guide.This guide effectively walks users through HTTP setup with clear options, practical examples, and good progression from basic to advanced usage. The multi-language examples and provider configurations are particularly helpful.
docs/features/providers.md (2)
28-33: Import aliasing is correct—no changes needed.The
github.com/maximhq/bifrost/corepath resolves to packagebifrost, so callingbifrost.Initis valid and consistent with the project’s established convention.
52-63: Simplify the request payload to avoid unnecessary pointers.Taking the address of a slice literal (
&[]schemas.BifrostMessage{…}) introduces an extra indirection that is easy to mis-use and uncommon in example code. Using a plain slice keeps the snippet compile-ready while still matching the*[]schemas.BifrostMessagetype via automatic address-of when the struct is taken.- response, err := bf.ChatCompletion(context.Background(), schemas.BifrostRequest{ + response, err := bf.ChatCompletion(context.Background(), schemas.BifrostRequest{ Provider: schemas.OpenAI, Model: "gpt-4o-mini", Input: schemas.RequestInput{ - ChatCompletionInput: &[]schemas.BifrostMessage{ - { - Role: schemas.ModelChatMessageRoleUser, - Content: schemas.MessageContent{ContentStr: &[]string{"Hello from OpenAI!"}[0]}, - }, - }, + ChatCompletionInput: []schemas.BifrostMessage{ + { + Role: schemas.ModelChatMessageRoleUser, + Content: schemas.MessageContent{ContentStr: bifrost.Ptr("Hello from OpenAI!")}, + }, + }, }, })Benefits:
• Eliminates the awkward&[]slice{}pattern
• Demonstrates the idiomaticbifrost.Ptr()helper already used throughout the codebase
• Keeps the example copy-pasteable without additional fixes⛔ Skipped due to learnings
Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#54 File: core/schemas/bifrost.go:46-49 Timestamp: 2025-06-04T09:22:18.123Z Learning: In core/schemas/bifrost.go, the RequestInput struct uses ChatCompletionInput *[]BifrostMessage (pointer-to-slice) rather than []BifrostMessage to properly represent union type semantics. For text completion requests, ChatCompletionInput should be nil to indicate "no chat payload at all", while for chat completion requests it should be non-nil (even if empty slice). This distinguishes between different request types rather than just empty vs non-empty chat messages.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#81 File: tests/core-providers/scenarios/utils.go:101-110 Timestamp: 2025-06-16T04:21:07.962Z Learning: In the Bifrost codebase, when a variable is already available, it's acceptable to use `&variable` directly to get its pointer rather than always using `bifrost.Ptr(variable)`. The `bifrost.Ptr()` helper is primarily for taking pointers of literals or expressions, not existing variables.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#55 File: core/providers/anthropic.go:526-550 Timestamp: 2025-06-04T09:29:46.287Z Learning: In core/providers/anthropic.go, the content field in formattedMessages is always of type []interface{} because it's explicitly constructed that way upstream in the prepareAnthropicChatRequest function. Defensive type casting for multiple types is not needed since the type is guaranteed by the construction logic.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#88 File: core/providers/mistral.go:170-176 Timestamp: 2025-06-16T06:56:55.290Z Learning: When JSON unmarshaling into pooled structs, slice fields like `Choices []schemas.BifrostResponseChoice` get fresh heap memory allocations from `json.Unmarshal()`. The slice data is not part of the pooled struct's memory, so defensive copying is unnecessary. Resetting pooled structs with `*resp = ResponseType{}` only clears slice headers, not the underlying data.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#65 File: transports/bifrost-http/integrations/utils.go:169-173 Timestamp: 2025-06-09T17:33:52.234Z Learning: The ChatCompletionRequest method in the Bifrost client follows a contract where the result parameter will never be nil if the error parameter is nil. This means when error checking passes (err == nil), the result is guaranteed to be valid and can be safely used without additional nil checks.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#81 File: tests/core-providers/scenarios/end_to_end_tool_calling.go:43-45 Timestamp: 2025-06-16T04:13:55.437Z Learning: In the Bifrost codebase, errors returned from client methods like ChatCompletionRequest are of type BifrostError, not the standard error interface. For testing these errors, use require.Nilf instead of require.NoErrorf since BifrostError doesn't work with the standard error assertion methods.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#81 File: tests/core-providers/scenarios/simple_chat.go:39-41 Timestamp: 2025-06-16T04:13:42.755Z Learning: In the Bifrost codebase, errors returned from methods like ChatCompletionRequest are of type BifrostError (a custom error type) rather than the standard Go error interface. Therefore, require.Nilf should be used for error assertions instead of require.NoErrorf.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#83 File: core/providers/mistral.go:168-170 Timestamp: 2025-06-15T14:24:49.882Z Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#67 File: transports/bifrost-http/integrations/anthropic/router.go:26-34 Timestamp: 2025-06-10T11:19:29.604Z Learning: The Generic router in transports/bifrost-http/integrations/utils.go already handles nil pointers from RequestConverter functions. When a RequestConverter returns a nil *schemas.BifrostRequest, the Generic router automatically returns an HTTP 400 error with "Invalid request" message, making additional nil checks in individual router implementations redundant.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#67 File: transports/bifrost-http/integrations/anthropic/router.go:26-34 Timestamp: 2025-06-10T11:19:29.604Z Learning: The Generic router in transports/bifrost-http/integrations/utils.go already handles nil pointers from RequestConverter functions. When a RequestConverter returns a nil *schemas.BifrostRequest, the Generic router automatically returns an HTTP 400 error, making additional nil checks in individual router implementations redundant.docs/architecture/README.md (1)
1-114: Documentation structure looks solidNavigation table, quick-start sections and diagram render cleanly. No broken anchors spotted and the Mermaid block is fenced correctly, so this page is good to go.
docs/features/providers/anthropic.md (1)
176-206: Duplicate heading breaks anchor generation
### Custom Headers & Enterprise Setupappears twice (Go and HTTP sections).
Markdown processors generate identical IDs, leading to broken in-page links. Rename one of the headings or nest it under the<details>summary.⛔ Skipped due to learnings
Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#55 File: core/providers/anthropic.go:483-494 Timestamp: 2025-06-04T10:04:30.181Z Learning: In the Anthropic provider (core/providers/anthropic.go), parallel tool calls support including the DisableParallelToolUse flag will be implemented in later commits as it's a relatively new feature that's not commonly used yet. The development approach prioritizes core functionality first.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#55 File: core/providers/anthropic.go:0-0 Timestamp: 2025-06-04T05:44:09.141Z Learning: For the Anthropic provider in core/providers/anthropic.go, it's acceptable to pass potentially malformed messages with invalid roles because Anthropic's API will return suitable error responses for role issues, eliminating the need for additional validation logging.docs/features/providers/openai.md (2)
240-248:ConcurrencyAndBufferSizeexample uses value level instead of pointer – inconsistent with earlier snippetEarlier in this file you embed the struct by value (
ConcurrencyAndBufferSize:), here you assign it by value again, while other docs (e.g. concurrency.md) treat the field as*ConcurrencyAndBufferSize. Readers will wonder which is correct.Stick to one style (pointer vs. value) across docs or add a note explaining both are accepted and the defaulting rules.
182-199: Field names & package imports out-of-sync with currentschemasdefinitions – sample will not compile
NetworkConfigin core currently exposes
DefaultRequestTimeoutInSeconds,MaxRetries,RetryBackoffInitial,RetryBackoffMax.
The snippet here switches to a shorterTimeout/Retriespair that does not exist, and it omits atimeimport while still usingtime.Millisecond/Second.Readers copy-pasting this block will hit
unknown field 'Timeout' in struct literal of type schemas.NetworkConfig undefined: timeConsider aligning with the canonical struct:
- NetworkConfig: schemas.NetworkConfig{ - BaseURL: "https://api.openai.com/v1", // Custom endpoint - ExtraHeaders: map[string]string{ - "OpenAI-Organization": "your-org-id", - "OpenAI-Project": "your-project-id", - "User-Agent": "MyApp/1.0", - }, - DefaultRequestTimeoutInSeconds: 60, - MaxRetries: 3, - RetryBackoffInitial: 200 * time.Millisecond, - RetryBackoffMax: 5 * time.Second, - }, + NetworkConfig: schemas.NetworkConfig{ + BaseURL: "https://api.openai.com/v1", + ExtraHeaders: map[string]string{ + "OpenAI-Organization": "your-org-id", + "OpenAI-Project": "your-project-id", + "User-Agent": "MyApp/1.0", + }, + DefaultRequestTimeoutInSeconds: 60, + MaxRetries: 3, + RetryBackoffInitial: 200 * time.Millisecond, + RetryBackoffMax: 5 * time.Second, + },…and add
import "time"to the snippet header.⛔ Skipped due to learnings
Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#84 File: core/providers/ollama.go:59-61 Timestamp: 2025-06-15T14:34:29.401Z Learning: The `CheckAndSetDefaults()` method on `*schemas.ProviderConfig` in Go does not return any error - it has a void return type and only sets default values on the configuration struct.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#54 File: core/schemas/bifrost.go:46-49 Timestamp: 2025-06-04T09:22:18.123Z Learning: In core/schemas/bifrost.go, the RequestInput struct uses ChatCompletionInput *[]BifrostMessage (pointer-to-slice) rather than []BifrostMessage to properly represent union type semantics. For text completion requests, ChatCompletionInput should be nil to indicate "no chat payload at all", while for chat completion requests it should be non-nil (even if empty slice). This distinguishes between different request types rather than just empty vs non-empty chat messages.docs/architecture/concurrency.md (1)
155-167:InitialPoolSizecomment wrongly claims “Global memory settings” are onBifrostConfig; in code these fields live at root level, not underAccountSmall but confusing – move the comment or show the full struct literal so users see where global settings belong.
⛔ Skipped due to learnings
Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#85 File: core/providers/anthropic.go:150-156 Timestamp: 2025-06-15T16:07:53.140Z Learning: In the Bifrost codebase, constructor functions are allowed to mutate input ProviderConfig objects in-place (e.g., setting default BaseURL values and trimming trailing slashes). This pattern is acceptable and doesn't need to be flagged as a code review issue.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#81 File: tests/core-providers/scenarios/automatic_function_calling.go:22-22 Timestamp: 2025-06-16T04:55:11.886Z Learning: In the Bifrost test suite (tests/core-providers), parallel tests using t.Parallel() are not being implemented currently. The team plans to add parallel test execution in future enhancements.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#84 File: core/providers/ollama.go:68-72 Timestamp: 2025-06-15T14:31:59.649Z Learning: Go 1.22 introduced the ability to range over integers. The syntax `for range n` where n is an integer will iterate from 0 to n-1, making `for range config.ConcurrencyAndBufferSize.Concurrency` valid syntax for iterating a specific number of times without needing an explicit counter variable. This feature requires Go module version 1.22 or later.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#84 File: core/providers/ollama.go:68-72 Timestamp: 2025-06-15T14:31:59.649Z Learning: Go 1.23 introduced the ability to range over integers. The syntax `for range n` where n is an integer will iterate from 0 to n-1, making `for range config.ConcurrencyAndBufferSize.Concurrency` valid syntax for iterating a specific number of times without needing an explicit counter variable.docs/architecture/request-flow.md (1)
300-310: Throughput / latency numbers need citation or “typical” qualifierListing 10 000 RPS and 59 µs overhead as definitive may be misleading on smaller instances or with plugins enabled. Add “measured on t3.xlarge with no plugins” (or similar) so expectations are set correctly.
docs/features/providers/README.md (1)
253-256: Minor grammar: add article before “Environment Variables”“Environment Variables: Use …” → “Use environment variables …”
Helps the sentence read naturally; optional polish.⛔ Skipped due to learnings
Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#55 File: core/tests/e2e_tool_test.go:29-30 Timestamp: 2025-06-04T04:58:12.239Z Learning: In the Bifrost project, environment variables should be used only for secrets (like API keys), not for general configuration. Test parameters like provider and model can be hardcoded at the start of test files for predictability and consistency.docs/features/integrations/README.md (1)
76-82: Grammar nit – singular vs plural“makes standard API call”
Should be “makes standard API calls” to agree with plural Your app.
⛔ Skipped due to learnings
Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#63 File: transports/bifrost-http/integrations/openai/router.go:0-0 Timestamp: 2025-06-09T14:03:34.227Z Learning: In the Bifrost HTTP transport layer (transports/bifrost-http/integrations/), request validation like checking for empty messages should be handled by the provider rather than at the transport layer. The transport layer should forward requests to Bifrost core/providers for validation.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#84 File: transports/bifrost-http/main.go:2-2 Timestamp: 2025-06-15T16:05:13.489Z Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#63 File: transports/bifrost-http/integrations/openai/types.go:89-119 Timestamp: 2025-06-10T11:00:02.875Z Learning: In the Bifrost OpenAI integration (transports/bifrost-http/integrations/openai/types.go), the convertOpenAIContent function currently only handles the last image URL when multiple images are present in a content array. The user Pratham-Mishra04 has acknowledged this limitation and indicated it's part of a larger architectural issue that will be addressed comprehensively later, rather than with piecemeal fixes.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#63 File: transports/bifrost-http/integrations/openai/types.go:264-285 Timestamp: 2025-06-10T12:58:45.501Z Learning: In the Bifrost OpenAI integration, tool calls should be allowed on any message role (not just assistant messages) and the downstream provider should handle validation. Users passing tool calls to non-assistant messages is considered deliberate behavior that should be preserved.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#83 File: core/providers/mistral.go:168-170 Timestamp: 2025-06-15T14:24:49.882Z Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#54 File: core/schemas/provider.go:148-148 Timestamp: 2025-06-04T03:57:50.981Z Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.docs/features/memory-management.md (2)
30-37: Outdated API –bifrost.Initno longer returns(client, error)Recent releases changed
Initto return(*bifrost.Client, cleanupFn, error). Verify the real signature and update the snippet so copy-paste works.
1-4: Missing article“deliver high performance with minimal memory footprint” → “deliver a high performance with a minimal memory footprint” or simply drop the article: “deliver high performance with a minimal memory footprint”.
⛔ Skipped due to learnings
Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#83 File: core/providers/mistral.go:168-170 Timestamp: 2025-06-15T14:24:49.882Z Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#54 File: core/schemas/provider.go:148-148 Timestamp: 2025-06-04T03:57:50.981Z Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#94 File: core/mcp.go:696-711 Timestamp: 2025-06-18T20:16:37.560Z Learning: For the Bifrost MCP implementation, performance optimizations like caching tool discovery results should be deferred until after core functionality is complete. The author prefers to implement core features first and handle optimizations as follow-up work.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#94 File: core/bifrost.go:823-845 Timestamp: 2025-06-18T15:15:51.323Z Learning: In the Bifrost project, the team prioritizes maintaining consistent error handling patterns over exposing detailed error context. All errors should be wrapped in the standard `BifrostError` structure rather than creating specific error types or exposing richer error details like exit codes or stderr output.docs/architecture/performance.md (1)
38-46: Latency claims may be unrealisticThe table cites 11 µs total overhead on t3.xlarge including queueing & pool hops. Unless backed by published benchmarks (linked), such numbers will be questioned by readers. Suggest adding a citation or clarifying that the figure excludes network & provider latency and was measured with an in-process mock.
docs/features/mcp-integration.md (1)
248-260: Enum casing mismatch
connection_type: "http"is lower-case, but the schema showsschemas.MCPConnectionTypeHTTPwhich JSON-marshals to"HTTP". Ensure the casing matches the actual JSON tags or users will hit validation errors.docs/features/plugins.md (1)
354-364: Cache key generation is non-deterministic
json.Marshal(map[string]interface{}{ ... })serialises maps in random key order → identical
requests can hash to different keys, breaking cache hits.Simplest fix: marshal a struct or sort the keys before hashing.
-func (p *CachePlugin) generateCacheKey(req *schemas.BifrostRequest) string { - data, _ := json.Marshal(map[string]interface{}{ - "provider": req.Provider, - "model": req.Model, - "input": req.Input, - "params": req.Params, - }) +func (p *CachePlugin) generateCacheKey(req *schemas.BifrostRequest) string { + payload := struct { + Provider schemas.Provider `json:"provider"` + Model string `json:"model"` + Input any `json:"input"` + Params map[string]any `json:"params,omitempty"` + }{req.Provider, req.Model, req.Input, req.Params} + + data, _ := json.Marshal(payload) // deterministic hash := sha256.Sum256(data) return fmt.Sprintf("%x", hash) }⛔ Skipped due to learnings
Learnt from: connyay PR: maximhq/bifrost#92 File: core/providers/utils.go:60-64 Timestamp: 2025-06-17T14:04:21.104Z Learning: The bifrost codebase uses string alias types (like `type ContextKey string`) for context keys consistently across multiple packages including plugins/maxim/main.go and transports/bifrost-http/tracking/plugin.go. This pattern should be maintained for consistency rather than switching to the canonical struct{} approach.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#64 File: transports/bifrost-http/integrations/genai/types.go:273-313 Timestamp: 2025-06-09T16:35:26.914Z Learning: In convertGenerationConfigToParams method in transports/bifrost-http/integrations/genai/types.go, pre-allocating the ExtraParams map is preferred over lazy allocation because the method has multiple potential ExtraParams assignments, making the computational overhead of conditional checks exceed the memory savings of an empty map.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#83 File: core/providers/mistral.go:168-170 Timestamp: 2025-06-15T14:24:49.882Z Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#88 File: core/providers/openai.go:202-210 Timestamp: 2025-06-16T06:56:51.547Z Learning: In Go, when JSON unmarshaling into a pooled struct, slices within the struct are freshly allocated by the JSON unmarshaler, not part of the pooled struct's original memory. Defensive copying of these slices is unnecessary since they don't reference pooled memory that could be reused.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#88 File: core/providers/mistral.go:170-176 Timestamp: 2025-06-16T06:56:55.290Z Learning: When JSON unmarshaling into pooled structs, slice fields like `Choices []schemas.BifrostResponseChoice` get fresh heap memory allocations from `json.Unmarshal()`. The slice data is not part of the pooled struct's memory, so defensive copying is unnecessary. Resetting pooled structs with `*resp = ResponseType{}` only clears slice headers, not the underlying data.docs/features/observability.md (2)
156-160: Potential divide-by-zero in success-rate calculation.successRate := float64(stats.SuccessRequests) / float64(stats.TotalRequests) * 100If
TotalRequests == 0(fresh start-up or provider disabled) this panics. Guard the divisor:var successRate float64 if stats.TotalRequests > 0 { successRate = float64(stats.SuccessRequests) / float64(stats.TotalRequests) * 100 }
25-38: Missing dependencies and alias mismatch in the import block.The snippet uses
syncand the symbolbifrost, but the import list lacks:"sync" bifrost "github.com/maximhq/bifrost/core"As written, the example will not compile. Add the missing imports and alias the core package if you intend to reference it as
bifrost.-import ( - "context" - "fmt" - "time" - "github.com/maximhq/bifrost/core" - "github.com/maximhq/bifrost/core/schemas" -) +import ( + "context" + "fmt" + "sync" + "time" + bifrost "github.com/maximhq/bifrost/core" + "github.com/maximhq/bifrost/core/schemas" +)⛔ Skipped due to learnings
Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#135 File: docs/core-package.md:105-116 Timestamp: 2025-06-27T17:07:39.420Z Learning: In Go, when importing a package, the identifier used to access it is determined by the `package` declaration in the Go source files, not the directory name. For the Bifrost project, the core directory files declare `package bifrost`, so importing `"github.com/maximhq/bifrost/core"` automatically makes it accessible as `bifrost.Init`, `bifrost.Ptr`, etc., without needing an explicit alias.Learnt from: connyay PR: maximhq/bifrost#92 File: core/providers/utils.go:60-64 Timestamp: 2025-06-17T14:04:21.104Z Learning: The bifrost codebase uses string alias types (like `type ContextKey string`) for context keys consistently across multiple packages including plugins/maxim/main.go and transports/bifrost-http/tracking/plugin.go. This pattern should be maintained for consistency rather than switching to the canonical struct{} approach.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#81 File: tests/core-providers/openai_test.go:1-2 Timestamp: 2025-06-16T04:29:53.409Z Learning: In the Bifrost project, the user prefers to use `package main` for test files in the tests/core-providers directory rather than more descriptive package names like `coreproviders_test`.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#81 File: tests/core-providers/scenarios/end_to_end_tool_calling.go:43-45 Timestamp: 2025-06-16T04:13:55.437Z Learning: In the Bifrost codebase, errors returned from client methods like ChatCompletionRequest are of type BifrostError, not the standard error interface. For testing these errors, use require.Nilf instead of require.NoErrorf since BifrostError doesn't work with the standard error assertion methods.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#103 File: .github/workflows/transport-dependency-update.yml:53-75 Timestamp: 2025-06-20T16:21:18.912Z Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#81 File: tests/core-providers/scenarios/complete_end_to_end.go:39-41 Timestamp: 2025-06-16T04:12:05.427Z Learning: In the Bifrost system, error returns are of type `BifrostError` rather than the standard Go `error` interface. Therefore, use `require.Nilf(t, err, ...)` instead of `require.NoError(t, err)` when checking for errors in Bifrost function calls.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#81 File: tests/core-providers/scenarios/simple_chat.go:39-41 Timestamp: 2025-06-16T04:13:42.755Z Learning: In the Bifrost codebase, errors returned from methods like ChatCompletionRequest are of type BifrostError (a custom error type) rather than the standard Go error interface. Therefore, require.Nilf should be used for error assertions instead of require.NoErrorf.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#81 File: tests/core-providers/scenarios/automatic_function_calling.go:22-22 Timestamp: 2025-06-16T04:55:11.886Z Learning: In the Bifrost test suite (tests/core-providers), parallel tests using t.Parallel() are not being implemented currently. The team plans to add parallel test execution in future enhancements.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#54 File: core/schemas/bifrost.go:46-49 Timestamp: 2025-06-04T09:22:18.123Z Learning: In core/schemas/bifrost.go, the RequestInput struct uses ChatCompletionInput *[]BifrostMessage (pointer-to-slice) rather than []BifrostMessage to properly represent union type semantics. For text completion requests, ChatCompletionInput should be nil to indicate "no chat payload at all", while for chat completion requests it should be non-nil (even if empty slice). This distinguishes between different request types rather than just empty vs non-empty chat messages.Learnt from: Pratham-Mishra04 PR: maximhq/bifrost#83 File: core/providers/mistral.go:168-170 Timestamp: 2025-06-15T14:24:49.882Z Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.docs/architecture/system-overview.md (1)
3-3: Throughput claim needs a citation“10 000+ RPS” is impressive but without a reference or benchmark link it reads as marketing.
Either footnote a reproducible benchmark (same section lists some numbers) or soften the statement (“Designed to handle …”).
| ### 🔧 **Go Package** - Choose if you: | ||
|
|
||
| - ✅ Are building a Go application | ||
| - ✅ Want direct code integration and type safety | ||
| - ✅ Need custom business logic and advanced features | ||
| - ✅ Prefer compile-time configuration validation | ||
| - ✅ Want maximum performance with minimal overhead | ||
|
|
||
| ### 🌐 **HTTP Transport** - Choose if you: | ||
|
|
||
| - ✅ Use any programming language (Python, Node.js, etc.) | ||
| - ✅ Want to keep AI logic separate from your application | ||
| - ✅ Need a centralized AI gateway for multiple services | ||
| - ✅ Prefer REST API integration patterns | ||
| - ✅ Want to scale AI requests independently | ||
|
|
||
| ### 🔄 **Drop-in Integrations** - Choose if you: | ||
|
|
||
| - ✅ Have existing OpenAI/Anthropic/GenAI code | ||
| - ✅ Want zero-code migration with instant benefits | ||
| - ✅ Need immediate fallback and load balancing | ||
| - ✅ Want to test Bifrost without changing your app | ||
| - ✅ Are migrating from LiteLLM or similar gateways | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Improve phrasing variety in decision criteria sections.
The decision criteria are helpful, but consider varying the phrasing to improve readability and avoid repetition.
### 🔧 **Go Package** - Choose if you:
-- ✅ Want direct code integration and type safety
-- ✅ Need custom business logic and advanced features
-- ✅ Prefer compile-time configuration validation
-- ✅ Want maximum performance with minimal overhead
+- ✅ Need direct code integration and type safety
+- ✅ Require custom business logic and advanced features
+- ✅ Prefer compile-time configuration validation
+- ✅ Seek maximum performance with minimal overhead
### 🌐 **HTTP Transport** - Choose if you:
-- ✅ Want to keep AI logic separate from your application
-- ✅ Need a centralized AI gateway for multiple services
-- ✅ Prefer REST API integration patterns
-- ✅ Want to scale AI requests independently
+- ✅ Prefer keeping AI logic separate from your application
+- ✅ Need a centralized AI gateway for multiple services
+- ✅ Favor REST API integration patterns
+- ✅ Require independent scaling of AI requests
### 🔄 **Drop-in Integrations** - Choose if you:
-- ✅ Want zero-code migration with instant benefits
-- ✅ Need immediate fallback and load balancing
-- ✅ Want to test Bifrost without changing your app
+- ✅ Seek zero-code migration with instant benefits
+- ✅ Need immediate fallback and load balancing
+- ✅ Prefer testing Bifrost without changing your app📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### 🔧 **Go Package** - Choose if you: | |
| - ✅ Are building a Go application | |
| - ✅ Want direct code integration and type safety | |
| - ✅ Need custom business logic and advanced features | |
| - ✅ Prefer compile-time configuration validation | |
| - ✅ Want maximum performance with minimal overhead | |
| ### 🌐 **HTTP Transport** - Choose if you: | |
| - ✅ Use any programming language (Python, Node.js, etc.) | |
| - ✅ Want to keep AI logic separate from your application | |
| - ✅ Need a centralized AI gateway for multiple services | |
| - ✅ Prefer REST API integration patterns | |
| - ✅ Want to scale AI requests independently | |
| ### 🔄 **Drop-in Integrations** - Choose if you: | |
| - ✅ Have existing OpenAI/Anthropic/GenAI code | |
| - ✅ Want zero-code migration with instant benefits | |
| - ✅ Need immediate fallback and load balancing | |
| - ✅ Want to test Bifrost without changing your app | |
| - ✅ Are migrating from LiteLLM or similar gateways | |
| ### 🔧 **Go Package** - Choose if you: | |
| - ✅ Are building a Go application | |
| - ✅ Need direct code integration and type safety | |
| - ✅ Require custom business logic and advanced features | |
| - ✅ Prefer compile-time configuration validation | |
| - ✅ Seek maximum performance with minimal overhead | |
| ### 🌐 **HTTP Transport** - Choose if you: | |
| - ✅ Use any programming language (Python, Node.js, etc.) | |
| - ✅ Prefer keeping AI logic separate from your application | |
| - ✅ Need a centralized AI gateway for multiple services | |
| - ✅ Favor REST API integration patterns | |
| - ✅ Require independent scaling of AI requests | |
| ### 🔄 **Drop-in Integrations** - Choose if you: | |
| - ✅ Have existing OpenAI/Anthropic/GenAI code | |
| - ✅ Seek zero-code migration with instant benefits | |
| - ✅ Need immediate fallback and load balancing | |
| - ✅ Prefer testing Bifrost without changing your app | |
| - ✅ Are migrating from LiteLLM or similar gateways |
🧰 Tools
🪛 LanguageTool
[style] ~31-~31: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...refer REST API integration patterns - ✅ Want to scale AI requests independently ### 🔄...
(REP_WANT_TO_VB)
[style] ~38-~38: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...mediate fallback and load balancing - ✅ Want to test Bifrost without changing your app ...
(REP_WANT_TO_VB)
🤖 Prompt for AI Agents
In docs/quick-start/README.md between lines 17 and 40, the decision criteria
sections use repetitive phrasing starting with "Want" and "Need." To improve
readability and variety, rephrase some bullet points using synonyms or different
sentence structures while keeping the meaning clear and concise. For example,
replace some "Want" statements with alternatives like "Looking for," "Seeking,"
or "Prefer," and vary sentence openings to avoid monotony.
| | Contribution Type | Skill Level | Time Commitment | | ||
| | --------------------------------------------------------- | ------------ | --------------- | | ||
| | **[🐛 Bug Reports](bug-reports.md)** | Any | 5-15 minutes | | ||
| | **[📝 Documentation](documentation.md)** | Any | 15-60 minutes | | ||
| | **[🧪 Testing](testing.md)** | Intermediate | 30-120 minutes | | ||
| | **[💻 Development](development.md)** | Advanced | 2-8 hours | | ||
| | **[🔌 Integrations](../features/integrations/README.md)** | Advanced | 4-16 hours | |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Fix typography in time range specifications.
Use en dashes instead of hyphens for time ranges to follow proper typography conventions.
-| **[🐛 Bug Reports](bug-reports.md)** | Any | 5-15 minutes |
-| **[📝 Documentation](documentation.md)** | Any | 15-60 minutes |
-| **[🧪 Testing](testing.md)** | Intermediate | 30-120 minutes |
-| **[💻 Development](development.md)** | Advanced | 2-8 hours |
-| **[🔌 Integrations](../features/integrations/README.md)** | Advanced | 4-16 hours |
+| **[🐛 Bug Reports](bug-reports.md)** | Any | 5–15 minutes |
+| **[📝 Documentation](documentation.md)** | Any | 15–60 minutes |
+| **[🧪 Testing](testing.md)** | Intermediate | 30–120 minutes |
+| **[💻 Development](development.md)** | Advanced | 2–8 hours |
+| **[🔌 Integrations](../features/integrations/README.md)** | Advanced | 4–16 hours |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| | Contribution Type | Skill Level | Time Commitment | | |
| | --------------------------------------------------------- | ------------ | --------------- | | |
| | **[🐛 Bug Reports](bug-reports.md)** | Any | 5-15 minutes | | |
| | **[📝 Documentation](documentation.md)** | Any | 15-60 minutes | | |
| | **[🧪 Testing](testing.md)** | Intermediate | 30-120 minutes | | |
| | **[💻 Development](development.md)** | Advanced | 2-8 hours | | |
| | **[🔌 Integrations](../features/integrations/README.md)** | Advanced | 4-16 hours | | |
| | Contribution Type | Skill Level | Time Commitment | | |
| | --------------------------------------------------------- | ------------ | --------------- | | |
| | **[🐛 Bug Reports](bug-reports.md)** | Any | 5–15 minutes | | |
| | **[📝 Documentation](documentation.md)** | Any | 15–60 minutes | | |
| | **[🧪 Testing](testing.md)** | Intermediate | 30–120 minutes | | |
| | **[💻 Development](development.md)** | Advanced | 2–8 hours | | |
| | **[🔌 Integrations](../features/integrations/README.md)** | Advanced | 4–16 hours | |
🧰 Tools
🪛 LanguageTool
[typographical] ~24-~24: If specifying a range, consider using an en dash instead of a hyphen.
Context: ...* | Any | 5-15 minutes | | **[📝 Documentation](doc...
(HYPHEN_TO_EN)
[typographical] ~25-~25: If specifying a range, consider using an en dash instead of a hyphen.
Context: ...md)** | Any | 15-60 minutes | | **[🧪 Testing](testing.md...
(HYPHEN_TO_EN)
[typographical] ~26-~26: If specifying a range, consider using an en dash instead of a hyphen.
Context: ... | Intermediate | 30-120 minutes | | **[💻 Development](develop...
(HYPHEN_TO_EN)
[typographical] ~27-~27: If specifying a range, consider using an en dash instead of a hyphen.
Context: ...* | Advanced | 2-8 hours | | **[🔌 Integrations](../...
(HYPHEN_TO_EN)
[typographical] ~28-~28: If specifying a range, consider using an en dash instead of a hyphen.
Context: ...egrations/README.md)** | Advanced | 4-16 hours | ### Quick Start 1. **For...
(HYPHEN_TO_EN)
🤖 Prompt for AI Agents
In docs/contributing/README.md around lines 22 to 28, the time range
specifications use hyphens instead of en dashes. Replace all hyphens in the time
commitment column (e.g., "5-15 minutes") with en dashes (–) to follow proper
typography conventions for ranges.
| result, err := client.ChatCompletionRequest(context.Background(), &schemas.BifrostRequest{ | ||
| Provider: schemas.OpenAI, | ||
| Model: "gpt-4o-mini", | ||
| Input: schemas.RequestInput{ | ||
| ChatCompletionInput: &[]schemas.BifrostMessage{ | ||
| {Role: "user", Content: "Hello, world!"}, | ||
| }, | ||
| }, | ||
| }) | ||
|
|
||
| if err != nil { | ||
| log.Printf("Health check failed: %v", err) | ||
| } else { | ||
| log.Printf("Health check passed: %s", result.Output.Message) | ||
| } | ||
| } |
There was a problem hiding this comment.
Example does not compile against current API; update call names & types.
ChatCompletionRequest was renamed to ChatCompletion, and BifrostMessage requires a MessageContent wrapper. The response fields also differ. A minimal, build-ready snippet:
- result, err := client.ChatCompletionRequest(context.Background(), &schemas.BifrostRequest{
+ resp, err := client.ChatCompletion(context.Background(), schemas.BifrostRequest{
Provider: schemas.OpenAI,
Model: "gpt-4o-mini",
Input: schemas.RequestInput{
- ChatCompletionInput: &[]schemas.BifrostMessage{
- {Role: "user", Content: "Hello, world!"},
+ ChatCompletionInput: []schemas.BifrostMessage{
+ {
+ Role: schemas.ModelChatMessageRoleUser,
+ Content: schemas.MessageContent{ContentStr: bifrost.Ptr("Hello, world!")},
+ },
},
},
})
- if err != nil {
- log.Printf("Health check failed: %v", err)
- } else {
- log.Printf("Health check passed: %s", result.Output.Message)
+ if err != nil {
+ log.Printf("❌ Health check failed: %v", err)
+ return
+ }
+ if len(resp.Choices) > 0 && resp.Choices[0].Message.Content.ContentStr != nil {
+ log.Printf("✅ Health check passed: %s", *resp.Choices[0].Message.Content.ContentStr)
+ }Keeping the docs in sync with the API avoids confusion for new users copying the sample.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In docs/guides/troubleshooting.md around lines 40 to 55, the example code uses
outdated API names and types: the method ChatCompletionRequest should be renamed
to ChatCompletion, and the BifrostMessage struct must wrap its content inside a
MessageContent field. Additionally, update the response handling to match the
current API's response structure. Modify the code accordingly to ensure it
compiles and runs with the latest API version.
| ### 🎯 Core Features | ||
|
|
||
| Essential Bifrost capabilities with examples for both Go package and HTTP transport usage. | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Minor grammar nit—add a comma after the introductory phrase.
-Essential Bifrost capabilities with examples for both Go package and HTTP transport usage.
+Essential Bifrost capabilities, with examples for both Go package and HTTP transport usage.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### 🎯 Core Features | |
| Essential Bifrost capabilities with examples for both Go package and HTTP transport usage. | |
| ### 🎯 Core Features | |
| Essential Bifrost capabilities, with examples for both Go package and HTTP transport usage. |
🧰 Tools
🪛 LanguageTool
[uncategorized] ~23-~23: Possible missing comma found.
Context: ...### 🎯 Core Features Essential Bifrost capabilities with examples for both Go package and H...
(AI_HYDRA_LEO_MISSING_COMMA)
🤖 Prompt for AI Agents
In docs/README.md around lines 21 to 24, add a comma after the introductory
phrase "Essential Bifrost capabilities" to correct the grammar. Insert the comma
immediately after "capabilities" so the sentence reads smoothly and follows
proper punctuation rules.
| ### Why am I getting "account is required" error? | ||
|
|
||
| You need to implement the `Account` interface: | ||
|
|
||
| ```go |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Add the missing article for clarity.
-### Why am I getting "account is required" error?
+### Why am I getting an "account is required" error?📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### Why am I getting "account is required" error? | |
| You need to implement the `Account` interface: | |
| ```go | |
| ### Why am I getting an "account is required" error? | |
| You need to implement the `Account` interface: | |
🧰 Tools
🪛 LanguageTool
[uncategorized] ~372-~372: You might be missing the article “an” here.
Context: ...? Troubleshooting ### Why am I getting "account is required" error? You need to...
(AI_EN_LECTOR_MISSING_DETERMINER_AN)
🤖 Prompt for AI Agents
In docs/guides/faq.md around lines 372 to 376, the heading "Why am I getting
'account is required' error?" is missing the article "an" before "account." Add
the article "an" to make the heading read "Why am I getting an 'account is
required' error?" for grammatical correctness and clarity.
| # Use env. prefix for sensitive values in config | ||
| { | ||
| "providers": { | ||
| "openai": { | ||
| "keys": [{"value": "env.OPENAI_API_KEY", "weight": 1.0}] | ||
| } | ||
| } | ||
| } | ||
|
|
||
| # Set in environment | ||
| export OPENAI_API_KEY="sk-your-actual-key" | ||
| ``` |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Duplicate security guidance
These lines largely repeat the earlier “Environment Variables” section. Consider merging them or adding an anchor link to keep the document shorter and reduce maintenance overhead.
🤖 Prompt for AI Agents
In docs/configuration/http-config.md around lines 509 to 520, the example
showing how to use environment variable prefixes for sensitive values duplicates
content from the earlier "Environment Variables" section. To fix this, remove
the redundant example here and instead add an anchor link pointing to the
original "Environment Variables" section for reference, keeping the document
concise and easier to maintain.
| "network_config": { | ||
| "base_url": "https://api.openai.com/v1", | ||
| "extra_headers": { | ||
| "OpenAI-Organization": "your-org-id", | ||
| "User-Agent": "MyApp/1.0" | ||
| }, | ||
| "default_request_timeout_in_seconds": 60, | ||
| "max_retries": 3, | ||
| "retry_backoff_initial": 200, | ||
| "retry_backoff_max": 5000 | ||
| }, | ||
| "concurrency_and_buffer_size": { | ||
| "concurrency": 20, | ||
| "buffer_size": 200 | ||
| }, | ||
| "proxy_config": { | ||
| "type": "http", | ||
| "url": "http://proxy.company.com:8080", | ||
| "username": "user", | ||
| "password": "pass" | ||
| } |
There was a problem hiding this comment.
Avoid plaintext credentials inside proxy_config
Storing proxy username / password literals in JSON violates the security guidance later in this file.
Prefer referencing environment variables:
- "proxy_config": {
- "type": "http",
- "url": "http://proxy.company.com:8080",
- "username": "user",
- "password": "pass"
- }
+ "proxy_config": {
+ "type": "http",
+ "url": "http://proxy.company.com:8080",
+ "username": "env.PROXY_USER",
+ "password": "env.PROXY_PASS"
+ }Add a note that PROXY_USER / PROXY_PASS must be exported in the shell.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "network_config": { | |
| "base_url": "https://api.openai.com/v1", | |
| "extra_headers": { | |
| "OpenAI-Organization": "your-org-id", | |
| "User-Agent": "MyApp/1.0" | |
| }, | |
| "default_request_timeout_in_seconds": 60, | |
| "max_retries": 3, | |
| "retry_backoff_initial": 200, | |
| "retry_backoff_max": 5000 | |
| }, | |
| "concurrency_and_buffer_size": { | |
| "concurrency": 20, | |
| "buffer_size": 200 | |
| }, | |
| "proxy_config": { | |
| "type": "http", | |
| "url": "http://proxy.company.com:8080", | |
| "username": "user", | |
| "password": "pass" | |
| } | |
| "proxy_config": { | |
| "type": "http", | |
| "url": "http://proxy.company.com:8080", | |
| "username": "env.PROXY_USER", | |
| "password": "env.PROXY_PASS" | |
| } |
🤖 Prompt for AI Agents
In docs/configuration/http-config.md around lines 140 to 160, the proxy_config
section currently includes plaintext username and password fields, which is
insecure. Remove these literal values and instead update the documentation to
show that proxy credentials should be referenced via environment variables like
PROXY_USER and PROXY_PASS. Add a note instructing users to export these
environment variables in their shell before running the application.
| ```bash | ||
| # Using Go binary | ||
| go install github.com/maximhq/bifrost/transports/bifrost-http@latest | ||
| bifrost-http -config config.json -port 8080 | ||
|
|
||
| # Using Docker | ||
| docker run -p 8080:8080 \ | ||
| -v $(pwd)/config.json:/app/config/config.json \ | ||
| -e OPENAI_API_KEY \ | ||
| maximhq/bifrost | ||
| ``` |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Pin the transport binary version instead of using @latest
go install ...@latest pulls HEAD, which may introduce breaking changes that the supplied docs/config are not compatible with.
Recommend locking to the tag that shipped with this docs revamp:
-go install github.com/maximhq/bifrost/transports/bifrost-http@latest
+go install github.com/maximhq/bifrost/transports/bifrost-http@vX.Y.Z # ← replace with current tagThis keeps reproducibility in line with semantic-version guarantees.
🤖 Prompt for AI Agents
In docs/configuration/http-config.md around lines 61 to 71, the installation
command uses `go install ...@latest`, which can pull breaking changes. Replace
`@latest` with the specific version tag that matches the current documentation
to ensure reproducibility and compatibility. Update the command to pin the
transport binary version explicitly instead of using `@latest`.
| ### **Environment Variables** | ||
|
|
||
| ```bash | ||
| # Required API keys | ||
| export OPENAI_API_KEY="sk-your-openai-key" | ||
|
|
||
| # Optional server configuration | ||
| export APP_PORT=8080 | ||
| export APP_POOL_SIZE=300 | ||
| export APP_DROP_EXCESS_REQUESTS=false | ||
| ``` |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Re-consider exposing non-secret runtime knobs via environment variables
Earlier project discussions indicate env-vars should be reserved for secrets (API keys, tokens).
Publishing server-tuning knobs (APP_PORT, APP_POOL_SIZE, APP_DROP_EXCESS_REQUESTS) as env-vars dilutes that convention and risks accidental drift between container-level settings and CLI/config file defaults.
Either:
-# Optional server configuration
-export APP_PORT=8080
-export APP_POOL_SIZE=300
-export APP_DROP_EXCESS_REQUESTS=falseor explicitly document that these are provided only for legacy/docker convenience and are not the recommended path for production.
🏁 Script executed:
#!/bin/bash
# Locate the http-config.md file in the docs directory
fd -t f http-config.mdLength of output: 58
Remove non-secret knobs from ENV examples
Per project conventions, environment variables should be reserved for secrets (API keys, tokens). Exposing APP_PORT, APP_POOL_SIZE, and APP_DROP_EXCESS_REQUESTS here dilutes that convention and risks drift between container-level settings and your CLI/config defaults. Please remove these exports (or, if you need to preserve them for legacy Docker usage, explicitly label them as Docker-only overrides and note they aren’t recommended for production).
• docs/configuration/http-config.md (lines 47–57)
Suggested diff:
# Required API keys
export OPENAI_API_KEY="sk-your-openai-key"
-# Optional server configuration
-export APP_PORT=8080
-export APP_POOL_SIZE=300
-export APP_DROP_EXCESS_REQUESTS=false📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### **Environment Variables** | |
| ```bash | |
| # Required API keys | |
| export OPENAI_API_KEY="sk-your-openai-key" | |
| # Optional server configuration | |
| export APP_PORT=8080 | |
| export APP_POOL_SIZE=300 | |
| export APP_DROP_EXCESS_REQUESTS=false | |
| ``` | |
| ### **Environment Variables** | |
🤖 Prompt for AI Agents
In docs/configuration/http-config.md between lines 47 and 57, remove the
environment variable exports for APP_PORT, APP_POOL_SIZE, and
APP_DROP_EXCESS_REQUESTS from the example since they are not secrets and
including them breaks project conventions. If these variables must be mentioned
for legacy Docker use, label them clearly as Docker-only overrides and note they
are not recommended for production. Otherwise, keep only the secret API key
export in the example.
| ```go | ||
| type BifrostConfig struct { | ||
| Account Account `json:"account"` | ||
| Plugins []Plugin `json:"plugins,omitempty"` | ||
| InitialPoolSize int `json:"initial_pool_size,omitempty"` // Default: 100 | ||
| DropExcessRequests bool `json:"drop_excess_requests,omitempty"` // Default: false | ||
| MCPConfig *MCPConfig `json:"mcp_config,omitempty"` | ||
| Logger Logger `json:"logger,omitempty"` | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Struct tags contradict current codebase conventions
BifrostConfig is shown with JSON tags, yet previous PRs removed those tags because the struct is never (un)marshalled. Leaving them in docs may confuse contributors.
-type BifrostConfig struct {
- Account Account `json:"account"`
- Plugins []Plugin `json:"plugins,omitempty"`
- InitialPoolSize int `json:"initial_pool_size,omitempty"`
- DropExcessRequests bool `json:"drop_excess_requests,omitempty"`
- MCPConfig *MCPConfig `json:"mcp_config,omitempty"`
- Logger Logger `json:"logger,omitempty"`
-}
+type BifrostConfig struct {
+ Account Account
+ Plugins []Plugin
+ InitialPoolSize int // Default: 100
+ DropExcessRequests bool // Default: false
+ MCPConfig *MCPConfig
+ Logger Logger
+}Please align the snippet with actual source to prevent outdated guidance.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ```go | |
| type BifrostConfig struct { | |
| Account Account `json:"account"` | |
| Plugins []Plugin `json:"plugins,omitempty"` | |
| InitialPoolSize int `json:"initial_pool_size,omitempty"` // Default: 100 | |
| DropExcessRequests bool `json:"drop_excess_requests,omitempty"` // Default: false | |
| MCPConfig *MCPConfig `json:"mcp_config,omitempty"` | |
| Logger Logger `json:"logger,omitempty"` | |
| } | |
| type BifrostConfig struct { | |
| Account Account | |
| Plugins []Plugin | |
| InitialPoolSize int // Default: 100 | |
| DropExcessRequests bool // Default: false | |
| MCPConfig *MCPConfig | |
| Logger Logger | |
| } |
🤖 Prompt for AI Agents
In docs/architecture/system-overview.md around lines 160 to 168, the
BifrostConfig struct includes JSON tags that contradict the current codebase
conventions since the struct is not marshalled or unmarshalled. Remove all JSON
tags from the struct fields in the documentation snippet to align with the
actual source code and avoid confusing contributors.
No description provided.