Skip to main content

​
Overview

When you have multiple plugins — both built-in and custom — the order in which they execute matters. A logging plugin should capture the final request, an auth plugin should validate before anything else runs, and a response transformer should run after the provider returns data. Plugin sequencing lets you control where your custom plugins execute relative to Bifrost’s built-in plugins (telemetry, logging, governance, etc.) and in what order they execute relative to each other.

​
How it works

Bifrost organizes plugins into three placement groups that execute in a fixed order:
Placement GroupPre-hooks (request)Post-hooks (response)
pre_builtinRuns firstRuns last
builtinRuns secondRuns second
post_builtinRuns thirdRuns first
Post-hooks execute in reverse order of pre-hooks (LIFO pattern). This means a pre_builtin plugin’s PreLLMHook runs first, but its PostLLMHook runs last — ensuring proper cleanup and state unwinding.

​
Ordering within a group

Within each placement group, plugins are sorted by their order value (lower executes earlier). Plugins with the same order preserve their registration order. Example: Three custom plugins configured as:
PluginPlacementOrderPre-hook runsPost-hook runs
auth-validatorpre_builtin01st5th (last)
request-enricherpre_builtin12nd4th
Built-in plugins——3rd3rd
response-loggerpost_builtin04th2nd
analyticspost_builtin15th (last)1st

​
Configuration

  1. Navigate to the Plugins page in the sidebar
  2. Click the Edit Plugin Sequence button (appears when you have at least one custom plugin installed) Plugin Sequence Editor
  3. Drag custom plugins above or below the Built-in Plugins block:
    • Plugins above the block get pre_builtin placement
    • Plugins below the block get post_builtin placement
  4. The order within each group is determined by position (top = lowest order value)
  5. Click Save Sequence to apply the changes
If your config.json file has plugin sequence configured, it will take precedence over the sequence configured in the UI after restarting Bifrost.

​
When to use each placement

​
pre_builtin — run before built-in plugins

Use this when your plugin needs to:
  • Validate or authenticate requests before any built-in processing
  • Enrich requests with data that built-in plugins should see (e.g., injecting headers or metadata)
  • Short-circuit requests before they reach governance checks or telemetry

​
post_builtin (default) — run after built-in plugins

Use this when your plugin needs to:
  • Transform responses after all built-in processing is complete
  • Log or analyze the final request/response (after governance, telemetry, etc.)
  • Add custom headers or modify the response before it reaches the client
When in doubt, use the default post_builtin placement. Most custom plugins — logging, analytics, response transformations — work best after built-in plugins have finished their processing.

​
Next steps