DEV Community: vancine-fan

Kimi K3 in OpenCode: What One Finished Coding Task Actually Cost

vancine-fan — Tue, 21 Jul 2026 00:36:29 +0000

Update — July 23, 2026: I published a fuller reproducible guide covering the Starter, OpenCode configuration, evidence JSON, measured run, and its limitations:
Kimi K3 in OpenCode: A Reproducible Starter and One Measured Agent Run

Kimi K3 launched with impressive benchmark results—and a lot of debate about its price.

For developers using coding agents, however, price per million tokens is only part of the story.

A more useful question is:

How much does it cost to finish an actual coding task—with file reads, edits, tool calls, and passing tests?

We ran one controlled Kimi K3 coding task through OpenCode and recorded the result.

Disclosure: I work on Vancine, a third-party API aggregation platform. Vancine is not Moonshot AI and is not an official Kimi service. The cost below is measured Vancine usage for one specific run, not official Kimi pricing or a fixed-price promise.

The task

The agent received a small repository containing a faulty leap-year implementation.

It had to:

inspect the source code and failing tests;
identify the bug;
edit the source file;
leave the test file unchanged;
run the actual test suite;
finish with all tests passing.

The run used OpenCode v1.18.3 inside an isolated Docker Linux ARM64 environment.

The result

Metric	Result
Completed model steps	6
Completed tool calls	7
File reads	5
Source edits	1
Shell commands	1
Failed tool calls	0
Total tokens	28,707
Duration	84.3 seconds
Tests passed	Yes
Measured Vancine usage	$0.19

The 28,707 total tokens included:

3,746 input tokens;
1,019 output tokens;
902 reasoning tokens;
23,040 cached-read tokens.

The run completed without recorded HTTP 429 responses, HTTP 5xx responses, provider errors, or permission failures.

You can inspect the sanitized machine-readable evidence here:

Kimi K3 OpenCode verification evidence

What this result proves

For this specific task, Kimi K3 successfully:

inspected multiple files;
understood the failing behavior;
made the required source change;
invoked the test command;
reached a passing solution.

The source file was modified, the test file remained unchanged, and no unexpected files were created.

What it does not prove

This is one controlled task—not a general benchmark.

It does not prove that:

every Kimi K3 task will cost $0.19;
every repository will complete in six steps;
Kimi K3 is universally better than Claude, GPT, GLM, or other models;
every OpenCode version or coding-agent client behaves identically;
$1 of starting credit will complete a particular agent task.

Cline and Roo Code configuration examples are included in the starter repository, but they have not yet been independently live-verified. Only the recorded OpenCode v1.18.3 task is verified.

Why cost per finished task matters

Coding agents rarely make one isolated API request.

A normal agent loop may:

read multiple files;
build and rebuild context;
reason about the change;
call tools;
edit code;
run tests;
inspect failures;
retry until the task is complete.

Because of that, the cheapest model per token is not necessarily the cheapest model per finished task.

A useful coding-model evaluation should report:

whether the task was completed;
whether the tests passed;
model steps;
successful and failed tool calls;
total tokens;
elapsed time;
final billed usage.

One task is not a leaderboard, but it is a more concrete starting point than benchmark scores or token prices alone.

Using Kimi K3 with OpenCode

Vancine exposes the model alias kimi-k3 through an OpenAI-compatible API.

A minimal OpenCode provider configuration looks like this:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "vancine": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Vancine",
      "options": {
        "baseURL": "https://vancine.com/v1",
        "apiKey": "{env:VANCINE_API_KEY}"
      },
      "models": {
        "kimi-k3": {
          "name": "Kimi K3"
        }
      }
    }
  }
}

Keep the API key in an environment variable:

export VANCINE_API_KEY="your-api-key"
opencode

Then select:

vancine/kimi-k3

Do not commit real API keys to source control or paste them into shared configuration files.

Direct API request

The same model can be called through the OpenAI-compatible Chat Completions endpoint:

curl https://vancine.com/v1/chat/completions \
  -H "Authorization: Bearer $VANCINE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      {
        "role": "user",
        "content": "Review this function and identify the bug."
      }
    ]
  }'

The Vancine model alias is kimi-k3. Kimi’s first-party documentation uses k3 for the official Kimi Code model ID, so always use the identifier required by the provider you are connecting to.

Reproduce the setup

The public starter repository includes:

OpenCode configuration;
Cline and Roo Code configuration examples;
cURL, Python, and Node.js requests;
offline configuration validation;
sanitized OpenCode evidence;
credential-safety guidance.

View the Kimi K3 API Starter on GitHub

You can also open the complete quick start here:

Kimi K3 API for coding agents

New Vancine accounts currently receive $1 in starting credit, with no credit card required.

Usage depends on the model, prompt size, context, tool loop, and number of requests. The starting credit does not guarantee that any particular coding task will complete within that amount.

The broader takeaway is simple:

For coding agents, measure the cost of reaching a tested solution—not just the price of generating a token.

Seedance + n8n: Build a Bounded Async Polling Workflow

vancine-fan — Fri, 17 Jul 2026 17:43:52 +0000

This article was originally published on XINGOD.ME. This DEV edition keeps the implementation complete while adapting the explanation for automation builders.

Video generation APIs are asynchronous by design. The first request does not return a finished MP4. It returns a task identifier that you must preserve while the provider queues, processes, and eventually completes—or fails—the job.

That changes the automation problem. A production-ready workflow must do more than “poll until done.” It must:

submit exactly once;
preserve task_id and loop configuration across every node;
wait between status requests;
stop immediately on success or failure;
enforce a hard polling limit; and
make the final timeout observable.

In this tutorial, the default polling budget is 5 seconds × 120 polls, or roughly 10 minutes. Both values are configurable, but the loop always remains bounded.

The state machine

At a high level, the workflow is:

submit
  → save task_id and loop state
  → wait
  → poll
  → merge the API response with carried state
  → completed / failed / timeout / continue

The tested n8n workflow uses these concrete nodes:

manualTrigger
  → setFields
  → submitTask
  → saveTaskId
  → waitInterval
       ├─→ pollTask ─────┐
       └─→ carryState ───┴─→ Merge (append)
                               → mergeState
                               → ifCompleted
                                  ├─ true  → outputResult
                                  └─ false → ifFailed
                                               ├─ true  → failNode
                                               └─ false → ifTimeout
                                                            ├─ true  → timeoutFail
                                                            └─ false → continuePolling
                                                                          → waitInterval

The branching around pollTask and carryState is the critical part. An n8n HTTP Request node replaces the current item with the HTTP response. Without a parallel state branch, the response can erase the loop counter and configuration needed for the next iteration.

1. Configure the request and polling budget

Start with an Edit Fields node named setFields:

model = Doubao-Seedance-1.5-pro
prompt = A timelapse of a flower blooming at sunrise
size = 1280x720
base_url = https://vancine.com
intervalSeconds = 5
maxPolls = 120

intervalSeconds and maxPolls are configuration, not hidden constants. A different workflow may need a shorter interval or a different deadline, but it should still have an explicit upper bound.

Store authentication in n8n Credentials, for example with a reusable Header Auth credential. Never paste a real API key into exported workflow JSON, screenshots, or code examples.

2. Submit once and normalize `task_id`

Configure submitTask as an HTTP Request node:

POST https://vancine.com/v1/video/generations
Content-Type: application/json

Send the configured model, prompt, and size in the JSON body. The exact supported models and request fields can change, so check the live documentation before using the workflow in production.

Immediately after submission, saveTaskId creates the loop envelope:

task_id = {{ $json.task_id || $json.id || ($json.data && $json.data.task_id) || ($json.data && $json.data.id) }}
base_url = {{ $('setFields').first().json.base_url || 'https://vancine.com' }}
intervalSeconds = {{ $('setFields').first().json.intervalSeconds || 5 }}
maxPolls = {{ $('setFields').first().json.maxPolls || 120 }}
poll_index = 0

The submit response is a receipt. task_id is the durable hand-off value for every later status request, error message, and audit record.

3. Wait, then fork response and state

Connect saveTaskId to a Wait node named waitInterval. Its amount is:

{{ $json.intervalSeconds || 5 }}

After the wait, send the same item to two nodes:

pollTask performs the status request.
carryState retains the state required by the next iteration.

pollTask calls:

GET {{$json.base_url}}/v1/video/generations/{{$json.task_id}}

carryState outputs:

task_id = {{ $json.task_id }}
poll_index = {{ $json.poll_index || 0 }}
maxPolls = {{ $json.maxPolls || 120 }}
intervalSeconds = {{ $json.intervalSeconds || 5 }}
base_url = {{ $json.base_url || 'https://vancine.com' }}

Both branches feed a Merge node configured in append mode. The resulting item list contains the API response and the carried loop state.

4. Merge locally and increment exactly once

The mergeState Code node makes no network request. It identifies the two appended items, merges them, and increments the counter from the carried item exactly once:

const items = $input.all();

const response =
  items.find(
    (item) =>
      item.json.status !== undefined && item.json.object !== undefined,
  ) || items[0];

const carried =
  items.find((item) => item.json.poll_index !== undefined) ||
  items[items.length > 1 ? 1 : 0] ||
  items[0];

const pollIndex = (carried.json.poll_index || 0) + 1;

const taskId =
  response.json.task_id ||
  response.json.id ||
  (response.json.data && response.json.data.task_id) ||
  (response.json.data && response.json.data.id) ||
  carried.json.task_id;

const status =
  response.json.status ||
  (response.json.data && response.json.data.status);

const metadata =
  response.json.metadata ||
  (response.json.data && response.json.data.metadata);

const data = response.json.data;
const error =
  response.json.error ||
  (response.json.data && response.json.data.error);

const resultUrl =
  (metadata && metadata.url) ||
  (data && data.result_url) ||
  (data &&
    data.data &&
    data.data.content &&
    data.data.content.video_url) ||
  '';

return [
  {
    json: {
      task_id: taskId,
      status,
      metadata,
      data,
      error,
      poll_index: pollIndex,
      maxPolls: carried.json.maxPolls || 120,
      intervalSeconds: carried.json.intervalSeconds || 5,
      base_url: carried.json.base_url || 'https://vancine.com',
      result_url: resultUrl,
    },
  },
];

The important invariant is:

const pollIndex = (carried.json.poll_index || 0) + 1;

The counter comes from the latest carried state, not from the initial state node. This is what allows the workflow to reach maxPolls and guarantees that a non-terminal task cannot loop forever.

5. Route completed, failed, and timeout separately

Run the terminal checks in order.

`ifCompleted`

Treat completed and the legacy value SUCCESS as success:

$json.status === 'completed' ||
$json.status === 'SUCCESS' ||
($json.data &&
  ($json.data.status === 'completed' || $json.data.status === 'SUCCESS'))

The true branch goes to outputResult, where you can return or persist result_url.

`ifFailed`

The false branch from ifCompleted reaches ifFailed. Treat failed and FAILURE as terminal errors:

$json.status === 'failed' ||
$json.status === 'FAILURE' ||
($json.data &&
  ($json.data.status === 'failed' || $json.data.status === 'FAILURE'))

Send the true branch to a Stop And Error node. A failed generation is a business terminal state, not a reason to keep polling.

`ifTimeout`

Only a non-terminal, non-failed item reaches ifTimeout:

($json.poll_index || 0) >= ($json.maxPolls || 120)

The true branch stops with a timeout error. The false branch reaches continuePolling.

continuePolling copies the latest values back into the loop:

task_id
poll_index
maxPolls
intervalSeconds
base_url

It then reconnects to waitInterval. With the defaults, the 120th non-terminal response enters the timeout branch instead of starting iteration 121.

6. Keep transport retries separate from task polling

A task that is still processing is not the same as an HTTP request that received a transient 429 or 5xx.

Use two separate budgets:

a small, explicit retry policy with backoff for transient transport failures;
the poll_index / maxPolls budget for valid task-status responses.

This separation prevents network noise from silently changing the business timeout. Also test the following paths independently:

completed;
failed;
timeout;
missing task_id;
429 and 5xx; and
malformed or unknown status values.

Log task_id, poll_index, the last status, and elapsed time. Never log the Authorization header.

Try the tested workflow

The public Seedance API Starter Kit includes the tested n8n workflow plus Node.js, Python, cURL, and Postman examples.

Additional resources:

Start with Vancine

New Vancine accounts receive $1 in free credit, with no credit card required. You can create an account here.

Credit usage depends on the selected model, inputs, duration, and current pricing. The $1 credit does not guarantee that any specific video generation will complete within that amount.

Bounded polling is a small architectural choice with a large operational payoff: every execution has an inspectable state, every terminal outcome has an explicit branch, and every loop has a known failure budget.