jimeng-free-api-all puts an OpenAI-shaped front end on top of Jimeng's web endpoints

It is a proxy for a consumer site, not a model you host

Jimeng AI Free is described in the README as an interface service for the Jimeng (Jimeng) AI platform, providing convenient image and video generation. The project description in the repository listing is more direct about the mechanism: it is a reverse proxy that turns the Jimeng web service into an API, and it supports 5.x and 4.x image models plus video generation, is OpenAI compatible, and has a built-in visual management console.

The distinction matters for anyone evaluating it. There is no model weights file, no inference server and no GPU requirement. What the project does is maintain a current picture of how the Jimeng website talks to its own back end, and then speak that dialect on your behalf while presenting OpenAI shaped routes.

The evidence for that is the changelog itself, which is long and dated, and which is largely a record of the upstream site changing. Entries cover a new image model mapping to an internal key, a new Seedance video model with its own model_req_key, resolution and benefit_type, an update to the request version parameters with web_version and da_version values, and the addition of sceneOptions to the metrics_extra request structure. A feature that only works because the upstream request format has not changed is a feature with a maintenance clock attached.

There is a stated provenance too. The README says the project is a secondary development based on LLM-Red-Team/jimeng-free-api, and thanks the original author. The author field in package.json names Vinlic, and the licence field there says ISC while the repository licence is GPL-3.0.

An account pool of encrypted cookies is the unit of capacity

The design decision that shapes everything else is the account pool. The August 2026 changelog entry records the addition of an account pool that can hold multiple Jimeng account cookies, with per account enable and disable, round robin calling, failure cooldown and status refresh, and the cookies are stored with AES-256-GCM encryption. A companion status endpoint, GET /v1/account/status, reports membership status, credit and remaining free credit without exposing the cookie itself.

Key management arrived in the same release. The management side can create multiple jm_ prefixed calling keys, and each can be enabled, disabled and revoked individually, and the console tracks the remaining credit and last used time per key.

The encryption key handling is documented in the Dockerfile rather than in prose, and the comment there is worth reading carefully. The account pool encryption key is passed as JIMENG_ACCOUNT_POOL_KEY, and the Dockerfile says it must be set and kept stable, because changing it means old accounts can no longer be decrypted. A portable build carries the same variable in portable/config/portable.env, and there was a release specifically fixing that path so the pool key and the account pool encryption key are passed into the service process at startup.

The capacity model follows from this. The README says the official service currently grants 66 credits daily, and that multiple tokens can be rotated to make the most of the free allowance. So throughput is bounded by the sum of the daily credit across the accounts in the pool, and adding accounts to the pool is the only way to add capacity.

The OpenAI surface is the point, and the console is the product

The developer facing pitch is standardisation. The /v1/chat/completions route is described as fully compatible with the OpenAI specification, so existing applications can point at it without rewriting their client code, and multimodal message formats are supported with images extracted automatically and used as reference images or as first and last video frames.

The model list is dynamic rather than hard coded, which is the more interesting mechanism. The /v1/models route, when called with an Authorization header, pulls the live image and video model configuration from the Jimeng website and caches it, with a refresh=true parameter to force a refresh and type=image or type=video to filter. When there is no token or the upstream call fails, the route falls back to a built in list. The generation routes then prefer the model_req_key, resolution and benefit information from that dynamic configuration, with a static mapping as the fallback, so a new upstream model does not necessarily require a code change.

The management console is where the real product surface is. The README describes a dashboard with a login screen, a statistics panel and a media library, and a feature table covering real time statistics for total calls and total credit consumed, live log viewing filtered by INFO, WARN and ERROR level with auto refresh and export, a media library that records every generated image and video with filtering and preview, credit tracking that computes the cost of each request, and a system settings page.

That last page is the one to know about, because it controls the browser transport mode, offering off, auto and full, and it shows dependency status, browser run status and the remembered model chain. The setting takes effect immediately and survives a restart, and the README states the console setting takes precedence over the environment variable.

A browser transport layer works around upstream risk control, at a cost

The v1.2.8 release, dated 2026-09-27, added the browser transport layer, and it is the most consequential thing in the project. Seedance 2.0 and 2.0 Fast requests, identified by the upstream model keys dreamina_seedance_40_pro and dreamina_seedance_40, are intercepted by the upstream risk control middleware with a ret=4013 response, which the changelog notes does not consume credit. When that happens, the service switches to using a real browser session on the Jimeng page to complete the signing and retries, transparently to the caller. Other models and routes are unaffected.

The cost is real and stated. The Docker image gains about 805MB because Chromium is preinstalled with the browser path and the --no-sandbox argument already configured, so the container works in the default auto mode with no extra configuration. A slimmer build is possible with the INSTALL_BROWSER build argument, and the README notes that the slim build needs JIMENG_BROWSER_TRANSPORT=off to match. The Dockerfile also sets JIMENG_BROWSER_EXECUTABLE and the browser arguments, and the runtime image installs Chromium with its font and certificate dependencies when the browser layer is enabled.

Error reporting was improved at the same time. The upstream 4013 and 1019 codes are no longer wrapped into a generic request failed message and instead return a distinct upstream risk control interception code, and if playwright-core is not installed or the browser fails to start, the original error is preserved rather than a dependency error being thrown. The optional dependency is declared as optionalDependencies in package.json, and the build treats playwright-core as external.

Docker is the deployment path, and the volume is not optional

The README gives a single container run as the deployment, using the prebuilt image:

docker run -it -d --init --name jimeng-free-api \
  -p 8001:8000 \
  -v jimeng-data:/app/data \
  -e TZ=Asia/Shanghai \
  ghcr.io/zhizinan1997/jimeng-free-api-all:latest

The port mapping exposes the container's 8000 on the host's 8001, and the console is then reached at http://localhost:8001. The volume mount is strongly recommended, because it persists the statistics, the media records and the administrator password, and the Dockerfile creates the data directory and declares a volume at /app/data with the database path set to /app/data/jimeng.db.

The image is built in two stages from node:22-alpine. The build stage installs python3, make and g++, because there is no prebuilt musl binary for the SQLite library, then installs dependencies with npm ci, builds with npm run build, and finally reinstalls production dependencies only. The runtime stage installs libstdc++ for the same library and copies across only the dist directory, node_modules, package.json, configs and public. The package.json engines field requires Node.js 22 or later, and the release notes mention that the project and the Windows portable package were unified on Node.js 22 plus to match the native module requirements of the SQLite library version 13.

There is also a portable/ directory in the repository for a Windows package, and a vercel.json at the root, which suggests a serverless deployment shape is at least considered.

Request shapes are narrow in ways that will surprise you

The upstream request contract is visible in the changelog, and some of it is a trap rather than a feature. The number of images is passed by putting the gen_count that corresponds to n into the upstream abilities.gen_option structure, and a previous release was needed to fix a mismatch where the upstream ignored the count and defaulted to four images. The n parameter now supports 1 to 8 with a default of one, and a warning is logged when the upstream returns more images than requested, which is a check on credit consumption rather than a convenience.

Reference images are limited to ten in total across all sources, and the /v1/images/generations route accepts a filePath array, a filePaths array and multipart multi file uploads, with images passed to Jimeng in upload order. Video first and last frames travel in the file_paths parameter.

Resolution and duration are partly inferred from the prompt, which is unusual and worth knowing about. Video duration defaults to five seconds for the 2.0 series and accepts integer values from four to fifteen, with a downgrade retry based on model capability. The system also detects aspect ratio keywords in the prompt and adjusts the output size, with a set of supported ratios for images and for video, and it also recognises Chinese language keywords for wide, tall and square output.

Not every combination works, and the README admits it. A known issue says that when a 4.x model is asked for 2K resolution, some accounts are rejected by the Jimeng server with an insufficient credit error code 1006, and the system automatically downgrades to 1K. The README states the problem may relate to the account type or to upstream server policy and that it is currently unresolved.

Licence ambiguity and a project that tracks a moving upstream

The licence situation needs a decision from you rather than from this article. The repository listing records GPL-3.0, the README's licence badge links to the LICENSE file, and the top level entries include a LICENSE file, while the package.json inside the repository declares license as ISC. Those are different grants, and the README does not explain the split. A licensing note is not legal advice, so the practical step is to read both files and decide which governs the distribution you are planning.

The other licensing-adjacent point is the account pool. The service stores third party account cookies encrypted and rotates them, which means your deployment holds credentials for accounts on someone else's service, and the upstream terms of that service are outside this repository. The README does not address that question at all, which is a silence worth noticing rather than filling in.

On maintenance, the last push was on 2026-09-27 and the repository is not archived. The release list shows v1.2.8 on 2026-09-27, v1.2.7 on 2026-09-25 and v1.2.6 on 2026-09-02, and the package version in package.json is 1.2.8, which matches. The cadence is fast, and the content of the releases makes clear that much of the effort goes into tracking the upstream site rather than into the proxy's own features.

The alternative to adopting this is to call the Jimeng service through whatever first party access you can obtain, or to use a hosted image and video API with a contract you can rely on. What you gain here is the OpenAI compatible shape, the local media library and the credit accounting, and what you give up is any promise about the upstream behaviour, because the upstream can change its request format, its model catalogue, its error codes and its risk control policy at any time, as this changelog demonstrates repeatedly.

Editorial conclusion

Adopt jimeng-free-api-all if you want OpenAI style image and video endpoints today and are willing to treat the upstream site as a moving target, since the model list, the request format and the risk control behaviour all change underneath the proxy. Do not adopt it if you need a stable production contract, a supported vendor or a licence position you can defend, because the project carries a GPL-3.0 licence in the repository while the package metadata declares ISC. Verify first which licence file governs your use, that the account pool keys you set are stable across restarts, and that the free daily credit of 66 points is enough for the volume you intend to run.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. zhizinan1997/jimeng-free-api-all on GitHub