fix: update max completion tokens to 96

[MusicMaster4]

No description provided.

[greptile-apps]

Greptile Summary

This PR loosens the commit-message length constraints: the API completion budget grows from 64 to 96 tokens, the hard 60-character truncation inside cleanMessage is removed, and the prompt guideline shifts from "MAX 60 characters" to a soft "Aim for ~100 characters" via a new MAX_MESSAGE_CHARS constant.

• MAX_COMPLETION_TOKENS is raised to 96 so the model is no longer cut off mid-word on slightly-longer messages.
• The hard .slice(0, 60) in cleanMessage is dropped in both the Conventional Commits scan loop and the fallback return, meaning output length is now bounded only by the API token cap (~380 chars) rather than enforced at the application layer.
• A new MAX_MESSAGE_CHARS = 100 constant feeds the prompt template, but as the comment notes it is a soft target only — nothing in code enforces it.

Confidence Score: 4/5

Safe to merge — the change relaxes a character-length constraint and raises the token budget, which is a straightforward and intentional loosening of output limits.

The core logic is sound: removing the hard 60-char truncation is consistent with the shift to a soft prompt guideline, and 96 tokens gives the model enough room for a clean Conventional Commit subject line. The main things to consider are the misleading MAX_ prefix on a constant that isn't enforced, and the ~100-char soft target exceeding the 72-char display convention of most git forges.

lib/commit-message.ts — specifically the MAX_MESSAGE_CHARS naming and the removal of hard truncation in cleanMessage.

Important Files Changed

Filename	Overview
lib/commit-message.ts	Bumps MAX_COMPLETION_TOKENS from 64 → 96, introduces MAX_MESSAGE_CHARS = 100 as a prompt-only soft target, updates prompt instructions, and removes the hard .slice(0, 60) truncation from cleanMessage

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant Caller
    participant generateCommitMessage
    participant git
    participant buildContext
    participant API as OpenAI / OpenRouter
    participant cleanMessage

    Caller->>generateCommitMessage: opts (path, provider, apiKey, model, language)
    generateCommitMessage->>git: rev-parse --is-inside-work-tree
    git-->>generateCommitMessage: "true"

    par parallel git reads
        generateCommitMessage->>git: status --porcelain
        generateCommitMessage->>git: diff HEAD --name-status
        generateCommitMessage->>git: diff HEAD
        generateCommitMessage->>git: ls-files --others
    end

    generateCommitMessage->>buildContext: status, nameStatus, diff, untracked
    Note over buildContext: Truncates diff at 6 000 chars
    buildContext-->>generateCommitMessage: context string

    generateCommitMessage->>API: "prompt + context, max_tokens = 96 (was 64)"
    Note over API: Model targets ~100 chars (soft, prompt-only guideline)
    API-->>generateCommitMessage: raw response

    generateCommitMessage->>cleanMessage: raw text
    Note over cleanMessage: Strips think tags, scans lines for CC_RE match — no char truncation
    cleanMessage-->>generateCommitMessage: final message (unbounded by chars)

    generateCommitMessage-->>Caller: commit message string

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant Caller
    participant generateCommitMessage
    participant git
    participant buildContext
    participant API as OpenAI / OpenRouter
    participant cleanMessage

    Caller->>generateCommitMessage: opts (path, provider, apiKey, model, language)
    generateCommitMessage->>git: rev-parse --is-inside-work-tree
    git-->>generateCommitMessage: "true"

    par parallel git reads
        generateCommitMessage->>git: status --porcelain
        generateCommitMessage->>git: diff HEAD --name-status
        generateCommitMessage->>git: diff HEAD
        generateCommitMessage->>git: ls-files --others
    end

    generateCommitMessage->>buildContext: status, nameStatus, diff, untracked
    Note over buildContext: Truncates diff at 6 000 chars
    buildContext-->>generateCommitMessage: context string

    generateCommitMessage->>API: "prompt + context, max_tokens = 96 (was 64)"
    Note over API: Model targets ~100 chars (soft, prompt-only guideline)
    API-->>generateCommitMessage: raw response

    generateCommitMessage->>cleanMessage: raw text
    Note over cleanMessage: Strips think tags, scans lines for CC_RE match — no char truncation
    cleanMessage-->>generateCommitMessage: final message (unbounded by chars)

    generateCommitMessage-->>Caller: commit message string

Loading

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
lib/commit-message.ts:27-28
The constant is named `MAX_MESSAGE_CHARS` but the accompanying comment explicitly says it is a soft target, not a hard maximum. The name implies enforcement that doesn't exist — `cleanMessage` no longer truncates, and the API cap (`MAX_COMPLETION_TOKENS = 96`) translates to roughly 300-380 characters at typical English token densities. Using the word "MAX" while the code says "we never hard-truncate" creates a false expectation for any reader or future maintainer. Renaming it to `TARGET_MESSAGE_CHARS` (or `SOFT_TARGET_MESSAGE_CHARS`) makes the intent immediately clear without needing to read the comment.

```suggestion
/** Soft target for the model prompt — we never hard-truncate the model output. */
const TARGET_MESSAGE_CHARS = 100;
```

### Issue 2 of 2
lib/commit-message.ts:36
**Soft target allows messages well beyond common git conventions.** The prompt now says "Aim for ~100 characters", but most git forges (GitHub, GitLab, Gitea) wrap or truncate the commit subject line at 72 characters, and conventional practice recommends 50–72 chars. With a 96-token hard ceiling and no character truncation in `cleanMessage`, the model can legally produce subjects up to ~380 chars while technically satisfying the "~100 char" guideline. Consider tightening the target to `~72` (or keeping `MAX 72`) so generated messages display cleanly in standard git tooling.

_{Reviews (1): Last reviewed commit: "fix: update max completion tokens to 96" | Re-trigger Greptile}

[greptile-apps]

The constant is named MAX_MESSAGE_CHARS but the accompanying comment explicitly says it is a soft target, not a hard maximum. The name implies enforcement that doesn't exist — cleanMessage no longer truncates, and the API cap (MAX_COMPLETION_TOKENS = 96) translates to roughly 300-380 characters at typical English token densities. Using the word "MAX" while the code says "we never hard-truncate" creates a false expectation for any reader or future maintainer. Renaming it to TARGET_MESSAGE_CHARS (or SOFT_TARGET_MESSAGE_CHARS) makes the intent immediately clear without needing to read the comment.

Suggested change

	/** Soft target for the model prompt — we never hard-truncate the model output. */
	const MAX_MESSAGE_CHARS = 100;
	/** Soft target for the model prompt — we never hard-truncate the model output. */
	const TARGET_MESSAGE_CHARS = 100;

Prompt To Fix With AI

This is a comment left during a code review.
Path: lib/commit-message.ts
Line: 27-28

Comment:
The constant is named `MAX_MESSAGE_CHARS` but the accompanying comment explicitly says it is a soft target, not a hard maximum. The name implies enforcement that doesn't exist — `cleanMessage` no longer truncates, and the API cap (`MAX_COMPLETION_TOKENS = 96`) translates to roughly 300-380 characters at typical English token densities. Using the word "MAX" while the code says "we never hard-truncate" creates a false expectation for any reader or future maintainer. Renaming it to `TARGET_MESSAGE_CHARS` (or `SOFT_TARGET_MESSAGE_CHARS`) makes the intent immediately clear without needing to read the comment.

```suggestion
/** Soft target for the model prompt — we never hard-truncate the model output. */
const TARGET_MESSAGE_CHARS = 100;
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Soft target allows messages well beyond common git conventions. The prompt now says "Aim for ~100 characters", but most git forges (GitHub, GitLab, Gitea) wrap or truncate the commit subject line at 72 characters, and conventional practice recommends 50–72 chars. With a 96-token hard ceiling and no character truncation in cleanMessage, the model can legally produce subjects up to ~380 chars while technically satisfying the "~100 char" guideline. Consider tightening the target to ~72 (or keeping MAX 72) so generated messages display cleanly in standard git tooling.

Prompt To Fix With AI

This is a comment left during a code review.
Path: lib/commit-message.ts
Line: 36

Comment:
**Soft target allows messages well beyond common git conventions.** The prompt now says "Aim for ~100 characters", but most git forges (GitHub, GitLab, Gitea) wrap or truncate the commit subject line at 72 characters, and conventional practice recommends 50–72 chars. With a 96-token hard ceiling and no character truncation in `cleanMessage`, the model can legally produce subjects up to ~380 chars while technically satisfying the "~100 char" guideline. Consider tightening the target to `~72` (or keeping `MAX 72`) so generated messages display cleanly in standard git tooling.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!