I keep commit-message drafts to one model request

A commit message is a small piece of documentation that someone will read without your current context. A model can help write it, but asking for five versions of every message is an easy way to spend money without improving your history. My default is one focused request, followed by a human edit. Here is the workflow I use to make that request useful.

Start with one change you can explain

Before asking a model to write anything, review the changes you intend to commit. Can you describe them as one coherent action? If a bug fix is mixed with unrelated formatting and an unfinished experiment, separate those changes first. A polished message cannot make a confusing commit easier to review.

Write a rough sentence in your own words. It might be: “I changed the retry behavior because failed uploads were being attempted forever.” This is not your final message. It is a check that you understand the purpose of the change before handing its description to a model.

Gather the evidence, not the whole repository

Give the model the relevant staged changes and a short explanation of the intent. Include nearby context only when it helps explain the behavior. A renamed variable rarely needs an entire module attached, and a small validation fix does not need the project’s full history.

Review this material before sending it. Remove credentials, personal information, private customer data, and anything your project does not permit you to share. Staging a change does not automatically make its contents appropriate for an external service.

Also separate evidence from intent. The changes show what you edited; your note explains why. If you do not know the reason for an inherited change, say so rather than inviting the model to invent one.

Set the message rules in the same request

Tell the model what a successful answer looks like. Ask for one commit message with a concise, imperative subject and a short body only when the reasoning needs it. If the repository has an established convention, describe it or provide one representative example.

A useful instruction is: “Draft one commit message from the supplied changes and intent. Describe the actual behavior change. Do not claim tests passed unless I provide results. Do not invent issue numbers, performance improvements, or user impact. Return only the proposed message.”

Add your rough explanation and the relevant changes to that same request. Keeping the task self-contained avoids a conversation that repeatedly sends the same context. Ask for alternatives only when you genuinely need to choose between different emphases.

Use a modest model and inspect the charge

This is usually a bounded writing task, not a request to redesign the software. A model such as Claude Haiku 4.5 is a reasonable starting point to evaluate against your own commits. Judge whether it stays faithful to the evidence before considering a more expensive option.

MyRelay gives an individual developer one key and one budget across supported models, with tokens and cost visible for each request. If you want to try this workflow through it, create a MyRelay account and start with a budget you are comfortable spending. Inspect the first few request costs rather than assuming a short answer always means a cheap request; the supplied changes also consume tokens.

Check every claim against the actual change

Read the draft beside the changes, not in isolation. For the upload example, “Limit upload retries after repeated failures” is useful only if the implementation really introduces a limit. A body claiming that uploads now recover automatically would be misleading if the change simply stops retrying.

Check the scope, the reason, and any testing claims. Replace vague language such as “improve reliability” with the concrete behavior when possible. If a few words are wrong, edit them yourself. Another model request is rarely necessary to repair one sentence.

Save the instruction, not a growing conversation

Once the workflow works, keep the reusable instruction and adapt the evidence for each commit. Start fresh rather than carrying yesterday’s changes into today’s request. The useful habit is simple: provide a focused change, request one grounded draft, verify it, and stop. Your history gets clearer without turning a small writing task into an open-ended AI expense.