braintrustdata · Abhijeet Prasad (AbhiPrasad) · Sep 23, 2026 · Sep 23, 2026 · Sep 23, 2026 · Sep 23, 2026
diff --git a/.agents/skills/commit-message/SKILL.md b/.agents/skills/commit-message/SKILL.md
@@ -1,169 +1,42 @@
 ---
 name: commit-message
-description: Generates a meaningful conventional commit message (title + body) from the current diff and conversation context. Use when asked to write, suggest, or generate a commit message for the current changes.
+description: Draft a conventional commit message from the current changes and conversation. Use when asked to write, suggest, or generate a commit message; do not commit unless asked.
 ---
 
 # Commit Message Generator
 
-Generate a conventional commit message based on the staged/unstaged diff and the surrounding conversation.
+Write a concise, accurate commit message that captures the intent of the current changes. Use the conversation for motivation and constraints; use the diff as evidence. Do not claim behavior or test results the changes do not support.
 
-## Conventional Commits Format
+## Gather context
 
-```
-<type>(<scope>): <short summary>
-
-<body>
-
-<footer>
-```
-
-**Types:**
-- `feat` — new feature
-- `fix` — bug fix
-- `ref` — code restructuring without behavior change (prefer `ref` over `refactor`)
-- `perf` — performance improvement
-- `test` — adding or updating tests
-- `docs` — documentation only
-- `chore` — build system, tooling, dependencies, config
-- `ci` — CI/CD pipeline changes
-- `style` — formatting, whitespace (no logic change)
-- `revert` — reverts a previous commit
-
-**Rules:**
-- Subject line ≤ 72 characters, lowercase, no trailing period
-- Imperative mood: "add feature" not "added feature"
-- Body wraps at 100 characters, explains *what* and *why* (not *how*)
-- Footer: `BREAKING CHANGE: ...` or `Fixes #<issue>` / `Closes #<issue>` if applicable
-- Scope is optional but encouraged when it adds clarity (e.g., `feat(auth):`, `fix(api):`)
-- Omit body if the subject line fully communicates the intent
-
-## Writing Style
-
-- Lead with the point. Be direct, technical, collaborative, and lightly casual.
-- Use plain words, contractions where natural, and short paragraphs.
-- Prefer `we` for shared decisions and `I` for genuine opinion or uncertainty. Do not hide uncertainty behind authoritative prose.
-- Ground claims in specifics: name the API, version, behavior, error, test, or file involved.
-- Put code, identifiers, filenames, versions, and literal values in backticks.
-- Give only the context needed to explain **context → change → reason/evidence → consequence or follow-up**.
-- Surface compatibility constraints, tradeoffs, risks, and intentionally deferred work plainly when relevant.
-- Use bullets for multiple distinct changes or findings; avoid unnecessary headings and polished filler.
-- Do not merely restate the diff. Explain why the implementation matters or how behavior changes.
-
-For a substantive change, actively consider including a compact code snippet, before/after example, or ASCII diagram when it explains behavior or data flow more clearly than prose. Keep it focused and omit it when it would be decorative or redundant. For example:
-
-````text
-Before: provider response -> wrapper-specific span
-After:  provider response -> shared integration hook -> normalized span
-````
-
-or:
-
-````python
-# Before
-wrap(client)
-
-# After
-client = wrap_client(client)
-````
-
-## Instructions
-
-1. **Collect the diff** — run `git diff HEAD` (staged + unstaged). If empty, try `git diff --cached` (staged only). If still empty, try `git status --short` and `git log --oneline -3` to understand the trajectory.
-
-2. **Review the conversation** — you already have the conversation history in context. Look for:
-   - Explicit intent from the user ("I'm adding X", "this fixes Y")
-   - Issue or ticket numbers mentioned
-   - Feature names, module names, or domain language used
-   - Any constraints or things the user emphasized
-
-3. **Identify ambiguities** — before generating, check if any of these are unclear:
-   - Is the primary intent a new feature, a fix, a refactor, or something else?
-   - Is there a scope (module/package/component) worth calling out?
-   - Are there breaking changes?
-   - Is there a related issue or ticket number?
-   - Does the diff span multiple unrelated concerns? (should be split into separate commits)
-
-4. **Ask for clarifications if needed** — if the intent is genuinely ambiguous from both the diff and the conversation, ask 1–3 focused questions before generating. Do **not** ask about things already clear from the context.
-
-5. **Generate the commit message** — produce exactly one commit message in a fenced code block:
-   - Pick the most specific `type` that fits
-   - Include a `scope` when it meaningfully narrows the change
-   - Write a crisp subject line in imperative mood
-   - Add a body if the change is non-trivial, explaining the reasoning
-   - Check whether a small before/after snippet or ASCII diagram would make a substantive change easier to review, and include one when it would
-   - Add footer entries for breaking changes or issue references
-   - **CRITICAL when committing:** preserve **real newline characters** in the commit body
-   - **Never** put literal `\n` text inside a quoted `git commit -m "..."` body and assume Git will turn it into line breaks — it will not
-   - If issuing `git commit` yourself, prefer these patterns in this order:
-     1. **Best for multiline bodies:** write the full message to a temp file and use `git commit -F <file>`
-     2. **Good for amendments:** write the full message to a temp file and use `git commit --amend -F <file>`
-     3. multiple `-m` flags, e.g. `git commit -m "subject" -m "first paragraph
-
-second paragraph"`
-     4. ANSI-C quoting, e.g. `git commit -m "subject" -m $'line 1\n\nline 2'`
-   - Prefer temp-file commits by default whenever the body has multiple paragraphs, bullets, or any non-trivial formatting
-   - Before finalizing, sanity-check that `git log -1 --format=medium` shows actual blank lines and wrapped paragraphs, not backslash-n sequences
-
-## Newline safety examples
-
-**Wrong:**
-
-```bash
-git commit -m "docs: add pi guide" -m "line 1\n\nline 2"
-```
-
-This stores the characters `\` and `n` literally in the commit message.
-
-**Correct:**
-
-```bash
-git commit -m "docs: add pi guide" -m $'line 1\n\nline 2'
-```
-
-or
-
-```bash
-git commit -m "docs: add pi guide" -m "line 1
-
-line 2"
-```
+From the repository root, inspect `git status --short`, `git diff HEAD`, and `git diff --cached`. Check untracked paths shown by status when they are part of the requested change. If there is no relevant diff, use recent commit history for context and say when there is not enough information to draft a reliable message.
 
-or use a temp file/editor.
+Review the conversation for the user's stated goal, issue references, and compatibility constraints. If multiple unrelated changes appear, mention that they may need separate commits instead of hiding them in one vague message.
 
-## Default execution preference
+## Format
 
-When the task is not just to suggest a commit message, but to actually run `git commit` or `git commit --amend`:
+Use Conventional Commit form:
 
-1. If the message has a body, prefer a temp file with `-F`
-2. If amending a commit with a body, prefer `git commit --amend -F <file>`
-3. Only use inline `-m` bodies when the formatting is trivially simple and you are certain real newlines will be preserved
-4. After committing, verify with `git log -1 --format=medium`
+```text
+<type>(<scope>): <imperative summary>
 
-This preference exists to avoid malformed commit bodies with literal `\n` sequences.
-
-## Output Format
-
-Present the final message in a fenced code block. If the message contains its own fenced snippet, use a longer outer fence so the full message remains copyable:
+<optional body>
 
+<optional footer>
 ```
-feat(auth): add OAuth2 PKCE flow for CLI login
 
-Replace the device-code flow with PKCE so the CLI can authenticate
-without opening a browser on headless machines. The previous flow
-required interactive browser consent which blocked CI usage.
+- Choose the most specific suitable type: `feat`, `fix`, `ref` (repository convention for behavior-preserving restructuring), `perf`, `test`, `docs`, `chore`, `ci`, `style`, or `revert`.
+- Add a scope only when it meaningfully narrows the change.
+- Keep the subject at 72 characters or fewer, lowercase, imperative, and without a trailing period.
+- Add a body when the subject alone does not explain the purpose or a meaningful behavior change. Keep it focused on what changed and why; wrap prose at about 100 characters.
+- Add `BREAKING CHANGE: ...` or an issue-closing footer only when the diff or conversation supports it.
 
-Closes #342
-```
+Use direct, specific language. Name relevant APIs, versions, errors, or files when they clarify the change. Avoid restating the diff, unsupported claims, decorative examples, and filler.
 
-Then briefly (1–2 sentences) explain the key decision made (type choice, scope, whether a body was needed).
+For substantive changes, prefer a compact code snippet or ASCII diagram in the body when it explains behavior or data flow more clearly than prose. Keep it focused and omit it when it adds no clarity.
 
-If you asked for clarifications and the user answered, incorporate those answers and output the final message immediately — no need to re-ask.
+## Output and commit execution
 
-## Commands
+For a message suggestion, return one copyable message in a fenced code block. Add at most one brief sentence explaining a non-obvious type or scope choice. Ask a focused question only when the intent cannot reasonably be inferred from the diff and conversation.
 
-```bash
-git diff HEAD
-git diff --cached
-git status --short
-git log --oneline -5
-```
+Do not run `git commit` or `git commit --amend` unless the user explicitly asks you to commit. When committing a multiline message, preserve real newline characters: prefer writing the message to a temporary file and using `git commit -F <file>` (or `git commit --amend -F <file>`). Multiple `-m` flags or ANSI-C quoting are acceptable for simple cases. Never assume literal `\n` inside ordinary quotes becomes a newline. After committing, verify the stored message with `git log -1 --format=medium`.
diff --git a/.gitignore b/.gitignore
@@ -25,3 +25,6 @@ tsconfig.tsbuildinfo
 
 # BTX spec cache
 py/src/braintrust/btx/.spec-cache/
+
+# bt sync pull/push checkpoints
+bt-sync/
diff --git a/py/src/braintrust/integrations/anthropic/_utils.py b/py/src/braintrust/integrations/anthropic/_utils.py
@@ -32,6 +32,8 @@ def __getattr__(self, name: str) -> Any:
     {
         "service_tier",
         "inference_geo",
+        "speed",
+        "fallback_credit",
     }
 )
 

diff --git a/...ic/cassettes/latest/test_anthropic_beta_messages_create_captures_compaction_metadata.yaml b/...ic/cassettes/latest/test_anthropic_beta_messages_create_captures_compaction_metadata.yaml