Claude Code refuses requests or charges extra if your commits menti...

Two branches have byte-for-byte identical source trees. On one branch, Claude Code completes a refactor. On the other, it refuses, asks for clarification, or consumes noticeably more paid usage. The only deliberate difference is an empty commit whose message contains OpenClaw.

That looks like keyword-based blocking or a hidden surcharge. It is also an easy experiment to misread.

A commit message can influence an agent only if it enters the agent’s context—perhaps because the tool ran git log, inspected repository metadata, or received history from an integration. And a provider does not need a special “OpenClaw price” for the second run to cost more. Refusals, retries, longer explanations, cache misses, and repeated tool calls all increase token consumption.

The useful engineering question is not “Does this word anger the model?” It is:

Which component observed the commit message, what decision did it make, and which metered operations followed?

There are three separate systems involved

Claude Code is more than a single model invocation. A typical coding-agent session has at least three relevant layers:

1. Context construction: Repository instructions, files, diffs, command output, and possibly Git metadata are assembled for the model.
2. Model and policy behavior: The model interprets that context and may answer, refuse, ask for clarification, or call another tool.
3. Usage accounting: Input, output, cache operations, tool loops, and any overage mechanism determine cost.

Conflating these layers produces dramatic but weak conclusions. A project name may alter model behavior without changing the price schedule. Changed behavior may then create additional metered work.

There is no sound basis for treating one expensive run as proof of a per-keyword tariff. Billing systems normally meter computational units such as tokens or requests. If a special pricing rule exists, it needs direct evidence in the itemized accounting—not inference from the final total.

First prove that the model can see the commit

Claude Code can inspect Git history, but that does not mean every commit message is automatically included in every model request. The agent might run commands such as:

git status --short
git diff --stat
git log -5 --oneline
git show --summary HEAD

It might also receive repository metadata from an IDE or wrapper. Behavior can change between versions, so do not assume a fixed context-building implementation.

A lightweight way to observe Git commands is to put a logging shim earlier in PATH:

REAL_GIT="$(command -v git)"
export REAL_GIT

mkdir -p "$HOME/.agent-trace/bin"

cat > "$HOME/.agent-trace/bin/git" <<'SH'
#!/usr/bin/env bash
printf '%s git' "$(date -u +%FT%TZ)" >> "$HOME/.agent-trace/git.log"
printf ' %q' "$@" >> "$HOME/.agent-trace/git.log"
printf '\n' >> "$HOME/.agent-trace/git.log"
exec "$REAL_GIT" "$@"
SH

chmod +x "$HOME/.agent-trace/bin/git"
export PATH="$HOME/.agent-trace/bin:$PATH"

Start a fresh Claude Code session from that shell, issue the test request, and inspect:

cat "$HOME/.agent-trace/git.log"

This is not perfect telemetry. An agent can read .git directly, use an absolute executable path, or receive metadata from another component. Still, it answers the first practical question: did the visible tool loop request history?

A common gotcha is asking the agent, “Can you see the commit message?” That changes the prompt and encourages it to inspect Git. Observe normal execution before adding diagnostic instructions.

Build a controlled reproduction

Use empty commits so the trees remain identical. Start from a disposable repository; do not rewrite shared project history merely to test a suspicion.

mkdir /tmp/commit-context-test
cd /tmp/commit-context-test
git init

printf 'def add(a, b):\n    return a + b\n' > math_utils.py
git add math_utils.py
git commit -m "initial implementation"

BASE="$(git rev-parse HEAD)"

git switch -c control
git commit --allow-empty -m "chore: refresh repository metadata"
CONTROL="$(git rev-parse HEAD)"

git switch -c treatment "$BASE"
git commit --allow-empty -m "chore: mention OpenClaw"
TREATMENT="$(git rev-parse HEAD)"

test "$(git rev-parse "$CONTROL^{tree}")" = \
     "$(git rev-parse "$TREATMENT^{tree}")" &&
  echo "Trees are identical"

Run the exact same task in fresh sessions on each branch—for example:

Add type annotations to math_utils.py. Do not change behavior. Run an appropriate syntax check.

Keep these variables fixed:

• Claude Code version and model selection
• Account and billing mode
• Repository instructions such as CLAUDE.md
• Environment variables and available tools
• Starting context and prompt text
• Network access and dependency state
• Time window, where practical

Do not compare one control run with one treatment run. Model sampling, transient tool failures, and backend changes make single trials noisy. Run paired trials and record structured results:

{
  "condition": "treatment",
  "run": 7,
  "model": "sonnet-4.6",
  "status": "completed",
  "input_tokens": 18420,
  "output_tokens": 1260,
  "cached_input_tokens": 9100,
  "tool_calls": 4,
  "git_log_invoked": true,
  "elapsed_seconds": 31
}

Ten to twenty pairs can reveal a large effect, although subtle differences require more data. Stop if the test becomes expensive; the goal is diagnosis, not a publishable benchmark.

Also add useful controls:

• A random unfamiliar project name of similar length
• OpenClaw in a source comment rather than a commit
• The phrase inside a benign sentence explaining the project
• A commit message containing only chore: metadata test
• A run where Git history is explicitly excluded from supplied context

If many unfamiliar names trigger clarification, the issue is probably ambiguity rather than a product-specific rule. If only Git-history exposure changes the result, context construction is the leading cause.

Why “extra charge” can appear without keyword pricing

Suppose a normal run uses 18,000 input tokens and 1,200 output tokens. A refusal followed by two retries uses 42,000 input tokens and 2,800 output tokens. At an illustrative rate of $3 per million input tokens and $15 per million output tokens:

def cost(input_tokens, output_tokens, input_rate=3, output_rate=15):
    return (
        input_tokens * input_rate / 1_000_000
        + output_tokens * output_rate / 1_000_000
    )

baseline = cost(18_000, 1_200)
retrying = cost(42_000, 2_800)

print(f"baseline: ${baseline:.3f}")
print(f"retrying: ${retrying:.3f}")
print(f"difference: ${retrying - baseline:.3f}")

The result is:

baseline: $0.072
retrying: $0.168
difference: $0.096

Those rates are examples, not current pricing for a named model. Substitute the rates from your provider or contract, including separate cache-read, cache-write, tool, and long-context charges where applicable.

The commit message itself is tiny—likely tens of tokens at most. Its direct input cost would be fractions of a cent. The meaningful cost comes from changed execution: another context upload, more reasoning, repeated commands, or a failed cache prefix.

In practice, cache instability is especially easy to miss. If a commit hash, timestamp, or branch name appears near the beginning of a cached prompt, every commit may invalidate a large reusable prefix. That can look correlated with a particular message while actually affecting all new commits.

Design API integrations so repository names cannot dominate behavior

When building directly with Claude, GPT, Gemini, or another model API, control the context rather than dumping an entire repository transcript into every request.

Send a narrow, structured task:

{
  "task": "Add Python type annotations without changing behavior",
  "allowed_actions": [
    "read tracked source files",
    "edit math_utils.py",
    "run python -m py_compile math_utils.py"
  ],
  "repository_context": {
    "changed_files": ["math_utils.py"],
    "relevant_diff": "",
    "commit_history_included": false
  },
  "constraints": [
    "Do not install dependencies",
    "Do not access network resources"
  ]
}

Useful implementation rules include:

• Include Git history only for tasks that need historical reasoning.
• Put stable instructions before volatile repository metadata to improve cache reuse.
• Cap tool iterations and token budgets.
• Treat refusals as terminal outcomes requiring inspection, not automatic retry signals.
• Log model, request ID, token categories, tool calls, and stop reason.
• Preserve the original refusal text for debugging.
• Never remove suspicious terms solely to bypass safeguards; remove irrelevant metadata because it is irrelevant.

Multi-model testing can help separate agent-wrapper behavior from model behavior. The same context contract can be exercised with Sonnet 4.6, Haiku 4.5, GPT-5.5, Gemini 3, or another available model. AI Prime Tech can be useful here when cheaper multi-model API access makes paired testing affordable, but normalize usage accounting before comparing costs: providers expose caching and reasoning consumption differently.

Model switching is not a method for evading a legitimate safety boundary. It is a diagnostic technique when the task is ordinary software engineering and you need to determine whether the trigger lives in your wrapper, prompt, model, or policy configuration.

Best practices for production coding agents

A production agent should make this class of incident boring to investigate.

• Record provenance: Know which files, commands, and metadata contributed to each request.
• Separate policy from billing: A refusal event and a usage event should have distinct logs.
• Budget each loop: Set maximum tool calls, input growth, and retries.
• Use semantic allowlists: Supply the diff and relevant files rather than indiscriminately attaching history.
• Version prompts and models: Otherwise a silent configuration change can masquerade as a keyword effect.
• Test names as untrusted text: Repository names and commit messages are data, not instructions.
• Avoid selective redaction: Removing only OpenClaw may hide the symptom while leaving prompt-injection and context-quality problems unresolved.

The trade-off is visibility. Excluding history lowers cost and reduces accidental policy triggers, but it also prevents the model from discovering why code evolved. For migration work, regression analysis, and blame-driven debugging, curated commit history may be valuable. Context should be task-dependent, not globally disabled.

Practical takeaways

• A commit message matters only if some component exposes it to the model or classifier.
• Higher cost does not establish a keyword surcharge; inspect token, cache, retry, and tool accounting.
• Reproduce the issue with identical trees, fresh sessions, paired trials, and multiple controls.
• Instrument Git access before asking diagnostic questions that alter agent behavior.
• Send APIs minimal, structured repository context and keep volatile metadata out of stable cache prefixes.
• Do not rewrite real history or evade safeguards to “fix” the symptom.
• If the effect remains reproducible, package the exact prompt, tree hashes, tool trace, versions, and itemized usage into a minimal bug report. That evidence is far more actionable than the commit message alone.