That is the purpose of this checklist. It is a writing and planning aid for a reference-image-led action. It does not describe an endpoint control, predict consistency, or report a tested output. The current FLAQ MiniMax H3 Image-to-Video page uses the product terms “MiniMax H3” and “Image to Video”; this article uses those terms only to keep the reader context clear.

Disclosure: I am the founder of FLAQ. This article introduces our MiniMax H3 image-to-video service and prompt resources. It does not report independent output testing.

Begin with what the reference actually shows

Before writing anything, look at the source image as if you were handing it to a collaborator who cannot infer your intent. Identify the subject, its position in the frame, nearby objects, the setting, the light, and the relationships that are visible. This is not a request to catalogue every detail. It is a way to avoid adding assumptions that are not present in the image.

Then choose one action that can be recognized in ordinary language. “The bicycle begins a gentle turn” is easier to check later than “make the scene dynamic.” “The cup moves toward the window” is more useful than “create elegant motion.” One action gives the brief a center of gravity. It also makes it easier to say what should remain visually coherent while that action unfolds.

The word continuity needs the same restraint. Here it means a desired relationship you want to describe before generation—for example, the same object placement, a stable garment color, or an unchanged room layout. It is not a claim that a service exposes a continuity setting or that the result will preserve any of those things.

Use the checklist before you generate

The following questions are deliberately modest. They help a reader prepare a clear brief, but they do not turn the brief into a technical guarantee.

1. What is the single visible action?

Write one subject and one change: a hand lifts a lid, a cyclist turns, a curtain moves in a breeze, or a person steps toward a doorway. Avoid stacking several unrelated events into the same request. When a scene contains a lot of activity, select the action that matters most to the viewer and leave secondary motion out unless it is necessary to understand that action.

This is not “prompt anatomy.” You do not need a universal formula for every image. You only need enough specificity to tell another reader what they should be able to observe if the action is represented.

2. Which visible details matter to the action?

List the few features that make the action legible. For a bicycle turn, that could be the rider’s direction, the bicycle’s orientation, and the curve of the path. For a cup moving across a table, it could be the cup, the tabletop, and the hand that initiates the movement. Keep the list tied to the scene rather than adding general-purpose phrases such as “perfect detail” or “cinematic quality.”

The goal is not to demand more from a tool. It is to prevent the brief from contradicting its own starting image. If an element is not visible and not relevant to the action, it usually does not belong on the checklist.

3. What do you want to stay visually coherent?

Choose only the constraints that serve the action. A short list might say that the subject remains the same subject, a distinct object remains in place, the room layout does not change, or the direction of movement stays understandable. Phrase these as desired visual checks, not as provider controls: “keep the cup and table relationship easy to follow” is a planning note; “lock the cup perfectly” makes a promise this checklist cannot support.

It helps to distinguish a constraint from an outcome. A constraint is what you ask the brief to preserve in the reader’s mental picture. An outcome is what you later inspect in an actual result. Keeping those separate prevents a planning document from pretending it has already verified anything.

4. Where should the action arrive, if anywhere?

Some actions need an end state to make sense. A door may finish partly open; a bicycle may complete the visible turn; a hand may set an object down. State a simple, observable destination when it helps the scene read clearly. Do not invent an elaborate sequence just to sound precise. The question is not how many beats you can write; it is whether a viewer could recognize the intended change from the starting image.

If there is no meaningful end state, say so. A curtain swaying, a candle flickering, or a person pausing can remain a small, contained action. Clear limits are often more useful than an overfilled instruction.

5. What must you not claim?

Finish with a boundary check. Remove statements that imply a guaranteed identity match, exact continuity, a provider feature you have not confirmed, or a result you have not inspected. Do not turn a reference image into proof that a future output will be stable. This last question protects the reader as much as the rest of the checklist: it leaves the difference between a well-formed request and an observed result visible.

Keep provider pages and prompt resources separate

It is tempting to collect every related term into one description, especially when a repository discusses rich prompt-planning ideas. The supplied MiniMax H3 prompt repository can be useful as a separate resource for thinking about creative briefs. Its repository material is not evidence that a FLAQ image-to-video page exposes the same concepts as inputs, modes, or controls.

The present task is deliberately narrow: plan an action from a single reference image and write down the desired visual relationships without calling them controls.

Make a short desk-side pass

Before you generate, read the plan once as a viewer rather than as its author:

1. Can I point to the subject and the starting state in the reference image?

2. Is there one main action that a viewer could recognize?

3. Did I keep only the visual relationships that matter to that action?

4. Did I describe desired coherence without presenting it as a setting or guarantee?

5. Would I know what to inspect afterward, without claiming the inspection has already happened?

If the answer to any question is no, simplify. A shorter plan with one clear action and a few relevant constraints is easier to review than a large block of instructions that tries to pre-solve every possible problem.

Plan clearly, then inspect honestly

A reference-led action benefits from a small amount of discipline before generation: observe what is already there, choose one visible change, name the relationships that matter, and avoid promises you cannot support. That is enough to make a request more intelligible without confusing planning language with product controls or independent testing.

Use the checklist to make your intent easier to communicate. Treat the generated result, if you create one, as a separate thing to examine on its own evidence.

But developers do not merge tokens. We merge patches that pass tests, stay inside scope, and survive review. A cheaper model can become the expensive choice after two repair turns and twenty extra minutes of inspection.

So this comparison uses a more useful unit:

Cost per accepted patch = total API and review cost divided by the number of changes you would actually merge.

TL;DR

As of July 27, 2026:

• Flaq AI lists Kimi K3 at $2.85 per million input tokens and $14.25 per million output tokens on its text-to-text route.

• Hashnode's current Opus 5 pricing analysis reports $5 input and $25 output per million tokens.

• An illustrative run using 80,000 input tokens and 8,000 output tokens costs about $0.342 with Kimi K3 and $0.60 with Opus 5.

• That gives Kimi K3 a 43% API-price advantage for the same token volume.

• The advantage disappears if Kimi's accepted-patch rate falls too far below Opus 5's or if it creates substantially more review work.

This is a cost framework, not a claim that either model wins every coding task.

Start with the rate card, not the verdict

The current comparison is:

Moonshot's first-party Kimi K3 rate is $3 input and $15 output per million tokens. The Kimi K3 text-to-text route on Flaq AI currently displays slightly lower rates and a free-trial entry point. Its model identifier is kimi-k3-text-to-text.

Moonshot describes Kimi K3 as a 2.8-trillion-parameter model with a one-million-token context window, designed for long-horizon coding and knowledge work. That is relevant to repository tasks, but a large window does not remove the need for careful context selection. The Flaq route is text-to-text, so your harness still needs to select, sanitize, and serialize the repository evidence.

Why price per token can mislead you

Suppose a task uses 80,000 input tokens and produces 8,000 output tokens:

Kimi K3
(0.08 × $2.85) + (0.008 × $14.25) = $0.342

Claude Opus 5
(0.08 × $5.00) + (0.008 × $25.00) = $0.600

At equal token volume, Kimi K3 costs 43% less. That is real, but it is only the price of one attempt.

For coding work, use:

cost per accepted patch =
  (API spend across all attempts + review labor)
  / accepted patches

Now imagine your own evaluation finds an 80% acceptance rate for Opus 5. With the sample costs above, Kimi K3 only needs an acceptance rate above 45.6% to remain cheaper before review labor:

Kimi break-even acceptance rate
= ($0.342 × 0.80) / $0.60
= 45.6%

That threshold is not a benchmark result. It is the point at which your measured data would flip the economic decision.

Review time can flip it again. A patch that passes tests but touches unrelated files may be technically valid and still expensive to approve.

A benchmark loop that catches the hidden cost

Use ten or more bounded repository tasks rather than one impressive demo. A useful task should require cross-file reasoning but still have objective acceptance criteria.

For example:

Trace the authentication token refresh path, identify one likely race condition, propose the smallest safe patch, add focused tests, and explain every changed file. Do not change dependencies or unrelated code. Never claim a test was run unless the harness actually ran it.

For every model run:

1. Start from the same commit.

2. Provide the same task, files, constraints, and test command.

3. Set the same maximum number of repair turns.

4. Apply the candidate patch only inside an isolated worktree or disposable branch.

5. Record tokens, retries, test results, review minutes, and the final accept/reject decision.

If one model receives the whole repository while the other receives five curated files, you are measuring the context pipeline as much as the models.

A small cost calculator you can reuse

The following Node.js snippet turns rate cards and measured acceptance rates into the metric that matters:

const rates = {
  kimiK3Flaq: { input: 2.85, output: 14.25 },
  claudeOpus5: { input: 5, output: 25 },
};

function runCost(rate, inputTokens, outputTokens) {
  return (
    (inputTokens / 1_000_000) * rate.input +
    (outputTokens / 1_000_000) * rate.output
  );
}

function costPerAcceptedPatch({
  rate,
  inputTokens,
  outputTokens,
  attemptsPerTask,
  acceptanceRate,
  reviewMinutes = 0,
  reviewerHourlyRate = 0,
}) {
  const apiCost =
    runCost(rate, inputTokens, outputTokens) * attemptsPerTask;
  const reviewCost = (reviewMinutes / 60) * reviewerHourlyRate;

  return (apiCost + reviewCost) / acceptanceRate;
}

const workload = {
  inputTokens: 80_000,
  outputTokens: 8_000,
  attemptsPerTask: 1,
  reviewMinutes: 0,
  reviewerHourlyRate: 0,
};

console.table({
  kimi: costPerAcceptedPatch({
    ...workload,
    rate: rates.kimiK3Flaq,
    acceptanceRate: 0.6,
  }),
  opus: costPerAcceptedPatch({
    ...workload,
    rate: rates.claudeOpus5,
    acceptanceRate: 0.8,
  }),
});

With those illustrative acceptance rates, the result is roughly $0.57 per accepted Kimi patch and $0.75 per accepted Opus patch before review labor. Replace every sample number with data from your repository.

Running the Kimi side through Flaq AI

Here is a minimal non-streaming request that keeps the first pass in a read-only review role:

const response = await fetch(
  "https://api.flaq.ai/api/v1/chat/completions",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.FLAQ_API_KEY}`,
      "Content-Type": "application/json",
      Accept: "application/json",
    },
    body: JSON.stringify({
      model: "kimi-k3-text-to-text",
      messages: [
        {
          role: "system",
          content:
            "You are a read-only code reviewer. Cite files and symbols. " +
            "Do not invent repository evidence or modify unrelated code.",
        },
        {
          role: "user",
          content:
            "Map the authentication refresh path, identify one likely race " +
            "condition, and propose the smallest patch plus focused tests.",
        },
      ],
      stream: false,
      max_tokens: 2400,
    }),
  },
);

if (!response.ok) {
  throw new Error(`${response.status}: ${await response.text()}`);
}

const result = await response.json();
console.log(result.choices?.[0]?.message?.content ?? result);

Keep the API key in an environment variable. Do not send credentials, customer data, or private source code unless the provider route and your security policy explicitly allow it. Also verify the live API documentation before production use because schemas, limits, and prices can change.

When the lower-priced route is actually the better choice

Kimi K3 is compelling for test-gated repository work where you control the harness: codebase mapping, bounded bug localization, migration planning, or a small patch with a deterministic test suite. Its lower listed rate gives it room for some retries while still beating Opus 5 on API cost.

Opus 5 may remain cheaper for a task where failure is expensive and your own data shows a materially higher first-pass acceptance rate or much shorter review time. The right answer can also differ between repositories. A model that performs well in a typed service with strong tests may struggle in a legacy monolith with implicit behavior.

Do not choose one model for every step. A practical pipeline can route exploratory analysis to the lower-cost model, then reserve the higher-cost model or a human reviewer for ambiguous, high-risk changes.

Practical verdict

For the same 80,000-input/8,000-output-token workload, Kimi K3's current Flaq rate is 43% below the reported Claude Opus 5 rate. That makes Kimi K3 a credible lower-cost coding route, not an automatic winner.

The decision becomes defensible only after you record accepted patches, repair turns, and review minutes on your own tasks.

Start with a non-sensitive repository, cap the number of retries, and use the Kimi K3 API free trial on Flaq AI to validate the route before running a larger comparison.

Which number changes your model choice most often: token price, first-pass success, or reviewer time?

Sources

• Moonshot AI: Kimi K3 technical overview

• Moonshot AI: Kimi K3 pricing

• Hashnode: Claude Opus 5 effort levels and real cost

• Flaq AI pricing

• Hashnode editor documentation