Key facts
| Vision input | Image understanding runs on the OpenAI-compatible chat completions endpoint with supported multimodal models |
| Example model | plugsky-gemma-4 handles text plus image inputs such as screenshots, forms and product photos |
| Model access | 30+ models from efficient to frontier tiers behind one key |
| Dedicated media endpoints | Image generation and editing endpoints are labelled coming soon |
| Deployment | Hosted, VPC, on-prem and air-gapped options on Enterprise |
| Data handling | Data encrypted at rest and in transit; API data is not used to train models |
| Audit | Per-request logs with model, tokens, latency and user; SIEM export; retention up to 7 years |
| Free plan | plugsky-micro and plugsky-lite, no card; 14-day full-access trial |
TL;DR
- Vision is the chat completions call you already make, with an image.
- Downscale images to control token usage without losing needed detail.
- JSON mode and function calling turn output into validated fields.
- Keep a labelled image set and run it on every model change.
- Route easy cases to efficient models and escalate only failures.
How it works, step by step
- Send one image with one instruction and inspect the raw completion.
- Add a JSON schema with JSON mode and validate fields server-side.
- Downscale images and compare accuracy against token usage.
- Build a labelled evaluation set of at least a few dozen images.
- Test an efficient multimodal model before escalating to frontier tiers.
- Add retries with backoff and route low-confidence results to review.
- Split keys per environment and enable logging before launch.
Original data
Try it yourself
Open the best AI model selector →
Why developers need image understanding
If you already call chat completions, you already know the vision API. Put the image in the message content alongside your instruction, and the same client, key and error handling apply. Start with one image per request, one clear question and a strict output schema; multi-image prompts are possible, but they make evaluation and cost harder before you have a baseline.
Two engineering details decide whether this ships. Image size drives token usage, so downscale to the smallest resolution that preserves the text or detail you need. And model choice drives cost, so measure a small model on your own images before assuming you need the frontier tier.
How vision works on the Plugsky API
Treat vision as a tiered pipeline rather than one model. An efficient multimodal model such as plugsky-gemma-4 reads the common cases — screenshots, forms, labels, product photos — and a frontier model handles ambiguity, dense layouts or long documents. Both are called through the same OpenAI-compatible chat completions endpoint, with image content in the message, and both support streaming and JSON mode. Image generation and editing endpoints are labelled coming soon; understanding is live today. For developers, the only new decisions are image size, output schema and which model tier earns its cost.
The controls developers should configure first
Constrain output rather than parsing prose. Use JSON mode to return typed fields, or function calling when the extraction should trigger an action such as opening a ticket or writing a record. Validate every field server-side and keep a confidence or flag field so your application can route ambiguous results to review.
For cost and reliability, build a tiny evaluation set of labelled images and run it whenever you change model, prompt or image preprocessing. Route easy cases to an efficient multimodal model and escalate only failures, retry transient errors with backoff, and keep scoped keys per environment so usage is attributable. Streaming still works, which matters when a user is waiting on a description.
A practical pilot path
Ship the smallest useful feature first: a single-image field extraction or description endpoint behind a queue. Prototype on the free plan, then move to a paid self-serve plan when usage grows. See the live pricing page for current plans.
Honest comparison
| Capability | Plugsky | Vision-only API vendor | Building in-house |
|---|---|---|---|
| Image understanding | Live on supported multimodal chat models | Usually the core product | You host and serve vision models |
| Image generation | Labelled coming soon | Often available today | Custom deployment work |
| API shape | OpenAI-compatible chat completions | Vendor-specific SDK | You standardise it yourself |
| Model choice | 30+ models behind one key | Narrower catalogue | One model per integration |
| Deployment | Hosted, VPC, on-prem and air-gapped | Usually hosted only | Your infrastructure only |
| Controls | Region pinning, BYOK, per-request audit logs, SIEM export | Varies by vendor | You build the pipeline |
Frequently asked questions
Do I need a special endpoint for images?
No. Send the image in the message content of the standard OpenAI-compatible chat completions call and read the normal response.
How do I keep vision costs predictable?
Resize images before sending, measure an efficient multimodal model on your own evaluation set, and escalate only the cases it fails. Flat monthly plans remove per-token surprises on self-serve usage.
Do we have to change our application code?
No. Image understanding uses the same OpenAI-compatible chat completions endpoint, so your SDK, auth and error handling carry over; the message content simply includes an image.
Is there a free plan?
Yes — plugsky-micro and plugsky-lite with 2 API keys and no credit card. A 14-day full-access trial is also available.
How is pricing structured?
Self-serve plans are flat monthly with unlimited fair-use usage and no per-token charges or overage fees. See the live pricing page for current plans.
Is image generation available?
Not yet — image generation and editing endpoints are labelled coming soon. Image understanding is live today on supported multimodal chat models.