ForHosting KIT · Developer Utilities

Write a commit message

Six months from now, 'fix stuff' tells nobody running git blame what actually changed or why. This endpoint reads a diff and returns a properly scoped Conventional Commits message, the kind that makes a changelog generator and a future teammate equally happy.

● StablePer request + per diff$0.003

Run — $0.003 + $0.0135/diff How it works & API

Use it from WebAPIEmailApp soonTelegram soon

Run it online

Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.

Why the message matters more than it seems

A commit message is read far more often than it's written: by a teammate scanning git log for context, by a changelog tool deciding whether a change is a feature or a fix, by whoever runs git blame on a broken line two years later trying to understand intent, not just diff content. A vague message erases all of that context at the exact moment it was cheapest to capture, right when the change was fresh in someone's head.

What you send

You submit a diff, either the staged changes or a specific commit range, and the API reads the actual additions and deletions rather than asking you to describe what you did. This matters because developers are notoriously bad at summarizing their own diffs accurately under deadline pressure, and a message generated from the diff itself reflects what changed, not what someone remembers changing.

The Conventional Commits shape

Conventional Commits is a lightweight specification that structures a message as a type, an optional scope and a short description, such as fix(auth): handle expired refresh tokens, and it exists because tooling depends on that structure: semantic-release and similar tools parse the type to decide whether a release is a patch, minor or major bump, and changelog generators group entries by type automatically. The response follows that convention, choosing the type, feat, fix, refactor, chore, docs, test and so on, based on what the diff actually does, plus a scope inferred from the files touched.

Where it fits your workflow

The natural integration is a pre-commit or prepare-commit-msg hook that submits the staged diff and pre-fills the commit editor with a suggested message a developer can accept as-is or edit in seconds. It also fits a batch cleanup scenario: rewriting a series of vague messages in a feature branch before it's squashed and merged, so the final history reads clearly.

What it won't invent

The message describes what the diff changes, not why a business decision was made or what ticket prompted it, since that context doesn't exist in the code itself. If you want a ticket reference or a longer body explaining motivation, add it after the generated summary line rather than expecting the API to guess context it was never given.

What you can do with it

Pre-commit hook automation

A prepare-commit-msg hook submits the staged diff and pre-fills a Conventional Commits message so the developer just reviews and confirms instead of composing from scratch.

Cleaning up a feature branch before merge

A developer with fifteen 'wip' commits regenerates clear messages for each one before an interactive rebase, so the squashed history actually explains the change.

Enforcing changelog-ready history

A team using semantic-release generates every commit message through the endpoint to guarantee the type prefix is accurate and the automated release version bump is correct.

Reviewing a large third-party diff

Before merging a vendored dependency update, a maintainer generates a summary commit message describing the actual scope of the change from the raw diff.

FAQ

Does it follow the Conventional Commits format?

Yes, it returns a type, an inferred scope where relevant, and a concise description following the Conventional Commits convention that tools like semantic-release depend on.

What do I need to submit, a description or the actual diff?

The actual diff. Reading real additions and deletions produces a more accurate message than asking you to summarize your own change from memory.

Can it generate a longer commit body, not just the summary line?

It focuses on an accurate type, scope and summary line; add a longer body yourself for business context like a ticket reference the diff itself can't reveal.

Is there a free tier?

There's no free tier — free tiers get abused and slow everyone down. Access runs on a prepaid ForHosting KIT balance: top up from $10.00 (it never expires) and each request is charged at its published price, so a call with no balance returns HTTP 402. No subscription, no tokens, no invented credits, and a failed task is never charged.

How much does each request cost?

$0.003 per request plus $0.0135 per diff, and you're billed only for tasks that complete successfully.

What happens if the request fails?

It retries automatically up to three times; a persistent failure returns a clear error with no charge.

Can I use it to rewrite messages in an old branch before squashing?

Yes, submitting each commit's diff individually and regenerating its message is a common way to clean up history before an interactive rebase.

Is the diff I submit kept afterward?

No. Submitted diffs and generated messages are deleted after the retention window and are never used for training.

For developers — API access

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

API endpoint

POSThttps://api.kit.forhosting.com/dev/commit-message

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, and soon from our app, email and Telegram.

Call it from your stack

curl -X POST https://api.kit.forhosting.com/dev/commit-message \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d &#39;{"input":"…"}'

const res = await fetch("https://api.kit.forhosting.com/dev/commit-message", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "input": "…"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev/commit-message",
    headers={"Authorization": f"Bearer {os.environ[&#39;KIT_KEY']}"},
    json={
    "input": "…"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/commit-message", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => &#39;{"input":"…"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"input":"…"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/commit-message", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Example request

{
  "input": "…"
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.commit_message",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Pricing

Per request$0.003

Per diff$0.0135

Published price — no tokens, no invented credits. A failed task is never charged.

Errors

HTTP	Code	Meaning
`401`	`unauthorized`	Missing or invalid API key.
`402`	`insufficient_balance`	Your balance doesn't cover the task price.
`404`	`unknown_type`	That task type doesn't exist.
`429`	`rate_limited`	Too many requests. Use the webhook instead of polling.
`422`	`task_failed`	The task failed after 3 retries. You are never charged for it.

Read the full KIT documentation →