DEV Community: vancine-fan

Use Vancine Models in Pi Without Maintaining models.json

vancine-fan — Mon, 31 Aug 2026 15:36:13 +0000

Vancine is now available in Pi through the community extension pi-provider-vancine.

Install

pi install npm:pi-provider-vancine

Restart Pi after installation.

Log in

Inside Pi, run:

/login

Choose Vancine, then paste your own Vancine API key into Pi's secret prompt. The extension uses Pi's credential store and does not create a separate credential file.

Choose a model

Run:

/model

Select a model under the Vancine provider and start using it. You do not need to create or maintain ~/.pi/agent/models.json for this setup.

The extension loads compatible Chat Completions models from Vancine's dynamic catalog. It caches and revalidates the catalog, so this is not a claim that every startup fetch is realtime.

Links

pi-provider-vancine is a community extension published and maintained by Vancine. It is not an official Pi or Earendil Works extension, partnership, certification, or endorsement.

One Endpoint, Four Coding Models: A Practical Switching Workflow

vancine-fan — Sun, 30 Aug 2026 16:52:20 +0000

Disclosure: I work on Vancine, the API platform used in the examples below. This article was prepared with AI assistance and reviewed against the live product documentation.

Coding agents do not always need the same model.

One task may benefit from an experimental vision-capable model. Another may need a lightweight flash model for a fast edit-test loop. The integration problem is that evaluating several models often means managing different endpoints, credentials, and request formats.

An OpenAI-compatible endpoint makes the comparison simpler: keep the client configuration fixed and change only the model field.

The four model IDs

This workflow uses four exact model IDs:

hy4-preview
deepseek-v4-flash-vision-exp
glm-5.3-flash
qwen3.8-flash

They are available through the same base URL:

https://vancine.com/v1

Current prices and catalog metadata can change, so I am deliberately not freezing them into this article. The live comparison page reads them from the pricing API.

Send the first request

Store the API key in an environment variable:

export VANCINE_API_KEY="your-api-key"

Then send a standard Chat Completions request:

curl https://vancine.com/v1/chat/completions \
  -H "Authorization: Bearer $VANCINE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3-flash",
    "messages": [
      {
        "role": "user",
        "content": "Fix this function so the tests pass."
      }
    ]
  }'

To try another model, change only this line:

"model": "qwen3.8-flash"

The endpoint, authorization header, and message format stay the same.

How I would approach model selection

These are selection hypotheses, not benchmark conclusions:

Hy4 Preview - worth considering when you want early access and can tolerate preview-level changes.
DeepSeek V4 Flash Vision Exp - worth considering for coding workflows that involve screenshots or other visual input.
GLM-5.3 Flash - a candidate for flash-class coding-agent loops and one of the models included in Vancine's Pi evaluation.
Qwen3.8 Flash - another flash-class candidate included in the same Pi evaluation.

A useful evaluation loop is:

Start with one representative task from your real workload.
Keep the prompt, tool configuration, and acceptance criteria fixed.
Change only the model ID.
Record correctness, tool behavior, latency, and total cost separately.
Repeat with several tasks before choosing a default.

This avoids treating one successful run as a general model ranking.

An important evidence boundary

The existing Vancine Pi coding-agent evaluation contains glm-5.3-flash and qwen3.8-flash.

It does not contain:

hy4-preview
deepseek-v4-flash-vision-exp

The evaluation contains a different model ID named deepseek-v4-flash, so its result should not be transferred to the vision-exp model.

The benchmark page should therefore be read as limited evidence from a single controlled task, not as proof that one model is universally faster or better.

Connecting a coding-agent client

The same base URL can be used with OpenAI-compatible clients. Vancine currently provides configuration guides for OpenCode, Cline, and Roo Code:

Open the coding-agent integration guides

These are configuration guides, not claims that Vancine is an official provider or partner of those tools.

The practical takeaway

The main benefit is not that one model wins every task. It is that model switching becomes cheap:

one endpoint;
one credential;
one request format;
four exact model IDs.

That makes it easier to evaluate models against your own repository and keep different defaults for different coding workloads.

Compare the four models with live pricing

8 Chinese AI models on the same Pi coding-agent task: what we measured

vancine-fan — Fri, 28 Aug 2026 16:14:44 +0000

Most model comparisons try to answer a question that is too broad: “Which model is best?” We wanted a smaller, reproducible question instead:

What happens when eight current Chinese AI models receive the same coding task through the same agent?

We used Pi as the coding agent and ran one isolated JavaScript task across these models:

GLM-5.3
GLM-5.3-Flash
Kimi K3
Qwen3.8-Max
Qwen3.8-Flash
DeepSeek-V4-Flash
DeepSeek-V4-Pro
MiniMax-M3

Method

Each run started from its own copy of the fixture. The test directory was kept unchanged, the work directory was checked for unexpected files, and raw run evidence was stored separately from the task workspace. The same Pi provider configuration and task contract were used for every model.

This is deliberately a narrow test. It does not measure architecture work, long-horizon debugging, frontend judgment, or performance on a real production repository.

What we measured

All eight models completed the task successfully. Across the complete run we recorded:

8/8 passing runs
45 Pi requests
94,502 tokens
$0.037618 production-audited billed cost

The public page includes the model-by-model table, runtime and token measurements, the Pi configuration, methodology notes, and a downloadable JSON file:

View the full benchmark and data

Why publish a small benchmark?

A small benchmark cannot tell you which model is generally better. It can still answer useful operational questions:

Can every model finish the same concrete agent task?
How many agent requests does the run take?
How many tokens are consumed?
Does the billed amount match the evidence in production logs?
Can someone else inspect the setup rather than trusting a screenshot?

For this task, the answer to the first question was yes for all eight models. The differences are in the detailed run data, not a winner label.

A note on cost

The total above is the audited amount recorded for these eight runs, not a forecast for arbitrary coding work. Agent cost depends heavily on task length, retries, context growth, and tool behavior. A real repository can be much more expensive than this small fixture.

Reproducing it

The benchmark page includes the Pi setup and downloadable structured results. If you repeat it, keep the task, tests, agent version, model IDs, timeout, and evidence rules fixed. Otherwise you are comparing different experiments.

Disclosure: I operate Vancine, the OpenAI-compatible API used for these runs. The page is published as product evidence, and the result should not be read as a general model ranking.

I would especially value feedback on the harness and on what the next coding-agent task should test.

I wanted a smaller OpenRouter catalog for Chinese models, so I built one

vancine-fan — Thu, 27 Aug 2026 13:05:34 +0000

OpenRouter is useful. I still use it when I need broad model coverage.

But for one part of my work, that broad catalog became friction. I mainly wanted the current flagship models from Qwen, Kimi, GLM, MiniMax, and DeepSeek. I kept sorting through old versions, free routes, provider variants, and model IDs.

So I built Vancine, a smaller OpenAI-compatible API focused on current Chinese models.

Disclosure: I run Vancine. This is a product post, not an independent comparison. English is not my first language, and I used an AI writing assistant to edit the wording.

What it does

Vancine uses one API key, one balance, and one OpenAI-compatible endpoint:

https://vancine.com/v1

The catalog is intentionally small. When a Chinese provider replaces a flagship model, I update the catalog and retire the older listing instead of keeping every generation around.

The same account also reaches Chinese image, video, audio, and 3D models. I started with text and coding workloads, but media access has become useful for people who do not want separate accounts with several Chinese providers.

The price comparison

These are the four exact paid listings I compared on August 27, 2026. Prices are USD per 1M tokens.

Model	Vancine input / output	OpenRouter input / output
qwen3.8-max	$1.60 / $4.80	$2.00 / $6.00
kimi-k3	$2.40 / $12.00	$3.00 / $15.00
glm-5.3	$1.12 / $3.52	$1.40 / $4.40
MiniMax-M3	$0.24 / $0.96	$0.30 / $1.20

That is 20% lower for these four listings. Free variants, promotional routes, and temporary provider discounts are excluded. I am not claiming that every model is cheaper.

The live pricing page is the source of truth because provider prices can change.

Moving an existing OpenAI client

The change is small:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["VANCINE_API_KEY"],
    base_url="https://vancine.com/v1",
)

response = client.chat.completions.create(
    model="qwen3.8-max",
    messages=[
        {"role": "user", "content": "Explain this failing test."}
    ],
)

print(response.choices[0].message.content)

OpenRouter model IDs include a provider prefix. Vancine IDs do not, so qwen/qwen3.8-max becomes qwen3.8-max.

Chat completions and streaming follow the OpenAI-compatible format. Provider-specific errors may differ, so I would still test the exact tool and model combination before moving production traffic.

What I have actually tested

I have run Pi against Kimi K3 through Vancine on a real edit-and-test coding task. It completed the tool loop and left the tests passing.

I have not independently verified every coding agent. I would rather publish one reproducible result than put a long compatibility matrix on the page and pretend every green check means the same thing.

When OpenRouter is still the better choice

If you need Claude, GPT, Gemini, Llama, and hundreds of provider routes behind one account, OpenRouter is the obvious fit. Vancine is for the narrower case: you mainly want current Chinese frontier models, a short catalog, and lower prices on the compared paid listings.

I am still deciding what a smaller provider needs to publish before developers will trust it with production traffic. Uptime history? Rate-limit details? Version pinning? Better cost exports?

If you work with these models, I would like to hear which one matters most.

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.