img2model for agents

A skill file, a machine-readable API reference, and the handful of rules that decide whether an automated client works or quietly burns someone's credits.

Machine-readable documentation

Fetch these directly. They are plain text, they contain no navigation or markup to wade through, and they are generated from the same source as the human pages, so they cannot describe a different API.

URLWhat it is
/llms.txt The index. Start here if you arrived without a link: it lists everything below, in the llms.txt convention.
/agents/skill.md A ready-made skill: the submit/poll/download loop in bash and Python, how to choose settings, and the five mistakes that cost a round trip each.
/api.md The complete reference in markdown - every endpoint, every field, every default, every rejection message. Read this when the skill file does not cover a field.
/api The same reference as an HTML page, for the human you are working for.

Installing the skill

For Claude Code, or anything else that reads a SKILL.md from a directory:

mkdir -p .claude/skills/img2model
curl -sL https://img2model.com/agents/skill.md -o .claude/skills/img2model/SKILL.md

Then set IMG2MODEL_API_KEY in the environment, and the agent has everything it needs. If your harness prefers a single fetched document over an installed file, point it at /api.md instead - the skill file is a convenience, not a requirement.

Getting a key, as an agent

You cannot create one. Registration and key generation both need a signed-in browser, deliberately - it is what keeps a key attached to a person who agreed to the terms and can see the bill. Ask the human you are working for to do three things:

  1. Register and click the link in the verification email. Free, and free credits arrive immediately.
  2. Generate a key on the profile page.
  3. Put it in an environment variable rather than pasting it into a chat - IMG2MODEL_API_KEY is the name the skill file expects.

A key is a spending credential. Never put one in a query string, a repository, a log line or a bug report. If one leaks, generating a new key on the profile page revokes it.

The loop, in full

POST /api/jobs/new           api_key + new_job_form[image] + settings   -> {"job_id": "..."}
POST /api/jobs/status/{id}   api_key                              -> {"state": "...", "finished": false}
POST /api/jobs/result/{id}   api_key                              -> the model, as bytes

States run NEW → QUEUED → IN_PROGRESS → COMPLETED | FAILED | REJECTED. Poll every 3-10 seconds; a default job finishes in about 41 seconds and costs 52 credits.

What breaks automated clients

  • A refusal is an HTTP 200 with success: false. Bad key, unknown job, impossible settings, no credits - all of them. A client that only checks the status code sails past every error this API produces.
  • finished is true for FAILED and REJECTED too. Exit the poll loop on finished, then check state == "COMPLETED" separately. Waiting for COMPLETED alone waits forever on a job that failed.
  • One job at a time, per account. A second submission is refused while an earlier job is unfinished. Batches have to run in sequence, each polled to completion.
  • Unknown field names fail the whole submission rather than being ignored, so a typo costs a round trip instead of silently producing a model at the defaults.
  • The account's plan caps polycount, texture size and Full PBR. Over the ceiling is a refusal, not a quietly reduced job, and nothing is charged for it. Do not retry it - the answer will not change. Relay the message, which names the setting and the plan that lifts it, and offer to re-run inside the plan. The table is in /api.md.
  • The generator is not reproducible. The same image and the same settings can return a meaningfully different mesh. One bad result says nothing about the parameters - and re-running costs credits again, so say so before you do it.
  • Check faces against the polycount you asked for. A result delivering a fraction of the request still renders as a plausible thumbnail and is not fine.

What to expect from the service

  • One image in, one model out. There is no mesh upload, no re-texturing of a model you already have, and no batch endpoint.
  • It is good at subjects that are already three-dimensional - objects, characters, vehicles, buildings. It is poor at flat artwork and logos.
  • Output is .glb, or a voxel model as .vox. Conversion to other formats is on you.
  • Run time depends on the picture as much as the settings: the same parameters can take 20 seconds on a simple object and 100 on a busy one. Treat any quoted duration as an estimate.
  • Jobs that fail cost nothing. Credits top up weekly on every account, free ones included.

Anything the reference does not answer, ask a person: contact us.