Inkling API Access: Tinker and Providers

Hello, Dora here. I saw one sentence that would cause trouble in an architecture review: “Use the inkling API through Tinker.” Close enough to sound right. Wrong enough to create work.

As of July 17, 2026, Inkling access has several paths: open weights, Tinker customization, Tinker testing inference, third-party hosted inference, and self-hosted endpoints. They are not interchangeable. This note is about keeping those paths separate before someone builds a production plan on the wrong one.

Inkling Access Paths at a Glance

Model weights, Tinker training API, hosted inference, and third-party providers

The official Inkling release says Inkling is open weights, available for fine-tuning on Tinker, available via APIs on providers including Together, Fireworks, Modal, Databricks, and Baseten, and published on Hugging Face as both the original checkpoint and an NVFP4 checkpoint.

That sentence carries four different operational meanings.

Access path	What it is for	What it is not
Model weights	Self-hosting, inspection, custom serving, framework work	A managed API by itself
Tinker	Training, fine-tuning, RL, adapters, checkpoints	A full production inference platform
Tinker-compatible inference	Testing Inkling or a fine-tuned checkpoint	High-throughput user-facing deployment
Third-party provider	Hosted inference without owning the cluster	A universal guarantee of same model ID, features, or limits
Self-hosted endpoint	Maximum control over weights, runtime, data, and routing	Low-effort deployment

That is the useful map. Everything else is detail.

The Inkling Hugging Face model card also says API access is available through third-party inference providers, while local deployment can use libraries such as SGLang, vLLM, TokenSpeed, Unsloth, and Hugging Face tooling. It lists text, image, and audio inputs with text output.

So yes, an Inkling endpoint can exist. But the owner of that endpoint depends on the path: your team, Tinker, Hugging Face routing, or a provider.

Why these paths solve different problems

Weights solve control.
Tinker solves customization.
Hosted inference solves access.
Self-hosting solves ownership.

Those are different jobs. I paused here because this is usually where teams start mixing language. “We have API access” might mean a Tinker sampling call, an Anthropic-compatible beta endpoint, a Fireworks on-demand deployment, a Baseten model API, a Together serverless call, or an internal vLLM cluster.

Those are not the same thing.

For an API buyer, the difference affects procurement and data routing. For a platform engineer, it affects GPU planning, observability, fallbacks, and latency. For an AI product team, it affects what can be promised in customer documentation.

Having many routes is useful. Having one name for all of them is not.

Tinker Is Not the Same as a General Inference API

Training, fine-tuning, adapter workflows, and saved states

Tinker is a training API. The Tinker documentation describes it as a cloud training API where the developer writes local training loops while Tinker handles distributed GPU work. It supports LoRA fine-tuning, SFT, RL, DPO, distillation, text and vision workflows, and models from 1B to 1T+ parameters.

That matters for Tinker Inkling. The point is not “send prompt, get answer” as the main product surface. The point is “run a controlled training or post-training workflow without managing the distributed training system.”

The data model reinforces this. A Tinker session can contain training runs, sampling clients, and checkpoints. Checkpoints can be sampler weights or saved training state. A sampler checkpoint can be used for sampling. A saved state can resume or branch training.

That is a training workflow. Not a generic hosted inference contract.

I would describe Tinker this way in internal docs:

Use Tinker to customize Inkling.
Use Tinker sampling to evaluate training runs.
Use Tinker checkpoints to save, compare, resume, or export model states.
Do not describe Tinker alone as the production Inkling inference API unless the exact production inference interface, throughput, latency, and support path are approved.

Simple distinction. Saves meetings.

What production inference still needs after customization

A customized checkpoint still needs a serving path.

That path might be a third-party provider that can deploy the checkpoint. It might be an internal endpoint. It might be a temporary testing route. It might be a future Thinking Machines production inference product. It is not automatically solved by fine-tuning.

Thinking Machines now documents Anthropic-compatible inference for Tinker. This is useful. It lets teams interact with base models and fine-tuned checkpoints through an Anthropic Messages-style interface, including model names such as thinkingmachines/Inkling or a tinker://... sampler checkpoint path.

The same page also says the interface is meant for testing and internal low-traffic use, not large high-throughput user-facing deployment. It says latency and throughput may vary during beta, and that production-grade inference is coming later.

That is the boundary. Do not sand it down.

Third-Party Inference Options

Provider availability, model IDs, pricing, rate limits, and context support

The official provider list is a starting point, not a production checklist.

Before anyone publicly claims Inkling hosted inference, I would require proof for each provider being named. Not a launch sentence. Not a screenshot. The current provider page or account-level model catalog.

The minimum record:

provider name
model ID
base URL or endpoint type
API format
pricing unit
rate limits
context length
max output tokens
supported input modalities
tool or function-calling support
logging and retention terms
whether the route is serverless, on-demand, provisioned, or dedicated
date checked
owner who approved it

Fireworks is a good example of why this matters. Its Inkling model page currently lists a Fireworks model path, marks the model as ready, describes on-demand deployment on dedicated GPUs, shows a 1040k-token context length, supports function calling and image input, and says serverless and fine-tuning are not supported there.

That is one provider’s shape. Another provider may expose serverless. Another may expose a different model ID. Another may support text and image but not audio. Another may put the model behind account-specific access.

So that’s where the bottleneck was. The question is not “is Inkling available through APIs?” The question is “which API, under which provider contract, with which features turned on?”

Tool support, multimodal inputs, logging, and fallback behavior

Tool support is not a yes-or-no feature across providers.

Inkling itself is trained for agentic and tool-use systems, and the model card frames it for coding assistants, RAG systems, chatbots, multimodal apps, and agentic products. But provider support still has to be tested at the endpoint layer.

A provider may support function calling in a text route but not with image input. A provider may support image input but not audio. A provider may have logs for request metadata but not full prompt retention controls. A provider may allow fallback routing, but the fallback model may not share Inkling’s context length, tool schema behavior, or reasoning-effort controls.

That last one is easy to miss. Fallback is not only uptime. It is behavior substitution.

For an Inkling inference API, I would test these before production:

normal text chat
image input
audio input, if the provider claims it
function calls or tools
structured output, if needed
long-context request near your real workload
streaming behavior
error codes
timeout behavior
retry behavior
provider-side logs
fallback model behavior

No unverifiable code sample belongs in the public doc. A model ID and a real provider page are enough.

Self-Host or Use a Hosted Provider

Control, compliance, latency, GPU capacity, and operational burden

Self-hosting is the control path. It gives the team direct authority over weights, network boundary, data residency, runtime, logging, and patch cadence. It also gives the team the full serving problem.

Inkling is not a small local model. The official release states 975B total parameters and 41B active parameters, with full weights on Hugging Face and an NVFP4 checkpoint for Blackwell systems. That means the self-hosted path needs GPU capacity planning, framework selection, quantization validation, KV-cache planning, observability, autoscaling, queueing, safety filters, and incident response.

Hosted providers move much of that burden away. They also introduce vendor questions: data handling, logs, region, uptime, model updates, rate limits, support escalation, and billing surprises.

I would split the decision this way.

Use a hosted provider when the team needs fast evaluation, does not want to own GPUs yet, can accept provider routing, and has clear data approval.
Use self-hosting when compliance, privacy, custom runtime behavior, deterministic versioning, or heavy sustained traffic justify the operational cost.
Use Tinker when the real task is customization.
Use Tinker testing inference when the real task is “does this checkpoint behave better?” not “can this run a customer-facing product?”

Good infrastructure makes you forget it is there. Bad routing decisions make everyone remember it.

FAQ

Who approves routing Inkling traffic through a third-party provider?

Approval should include the API buyer or product owner, platform engineering, security, legal or privacy, and the team that owns production support. If the traffic includes customer data, add the data governance owner. If the provider will receive regulated or sensitive inputs, do not treat this as a normal model switch.

The approval record should name the provider, endpoint, model ID, data categories, logging policy, region, rate limits, pricing unit, and fallback plan.

What proof is needed before claiming API availability publicly?

Keep the official Thinking Machines release, the provider’s current model page or catalog entry, the provider’s pricing or account quote, the model ID, context limit, supported modalities, tool support notes, rate limits, and the date checked.

Do not say “Thinking Machines API” if the path is actually a third-party provider. Do not say “Tinker inference API” if the path is a beta testing interface. Name the route.

How should teams respond if a provider changes model IDs?

Freeze the old model ID in the incident or change record, capture the new ID, check whether behavior changed, rerun smoke tests, and update public docs only after engineering and support approve the wording.

If the old ID still resolves as an alias, record whether it is guaranteed or temporary. If it does not resolve, update examples, SDK defaults, eval configs, fallback routing, and customer-facing docs at the same time. Half-updated model IDs are how support tickets reproduce.

Conclusion

The clean inkling API story is not one API.

It is a set of access paths. Hugging Face gives the weights and model evidence. Tinker gives customization and training workflows. Tinker-compatible inference gives testing access, not the full production inference promise. Third-party providers give hosted inference, each with its own model ID, pricing, limits, modalities, and support terms. Self-hosting gives control, and takes the operational bill with it.

That is the boundary I would keep in every architecture note.

If the team wants customization, start with Tinker. If it wants production traffic, evaluate a provider or self-hosted Inkling endpoint. If it wants to claim public API availability, keep the receipts. This conclusion has an expiration date - provider catalogs change fast.

Previous posts: