Inkling and the new era of open-weights customization

You know that feeling when a tool works great… until you need it to work your way?

For most large language model (LLM) users, “your way” usually meant paying for another black-box plan, or waiting for a new feature request to be granted. The “open-weights” shift tries to break that loop: instead of renting a model’s outputs, you get access to its parameters (the learned knobs inside the neural network) so you can adapt it for your product, your domain, and your constraints.

Thinking Machines’ Inkling is a good example of this philosophy—especially because it’s built for customization, not just for showing off performance. Inkling is a multimodal Mixture-of-Experts transformer with 975B total parameters and 41B active parameters, supports up to a 1M-token context window, and was pretrained on 45 trillion tokens of text, images, audio, and video. (thinkingmachines.ai)

But the more interesting story isn’t just the size. It’s the workflow: Inkling is released alongside a fine-tuning platform (Tinker), and the release even demonstrates a self-improvement loop where the model helps generate its own fine-tuning objective, trains, evaluates, and then switches to the improved weights.

Open weights vs “API-only” models

Before diving into the details, it helps to name what’s different.

• Closed / API-only model: You send input, get output, and the model’s internals stay hidden.
• Open-weights model: The model weights are available so you can deploy and fine-tune it locally or in your infrastructure.

Open weights don’t magically solve every problem—fine-tuning still requires careful data, evaluation, and safety work. But they change the practical options:

• You can tailor behavior (tone, formatting, tool use patterns).
• You can adapt to domain language and documentation.
• You can control compute trade-offs in deployment.

Inkling is designed for exactly this “customize it into your workflow” mindset.

Why Mixture-of-Experts changes the scaling math

Inkling is described as a Mixture-of-Experts (MoE) transformer. That phrase sounds like jargon, so let’s translate it into something concrete.

A transformer is a neural network architecture that processes sequences (text tokens, image patches, audio tokens) using attention mechanisms.

A Mixture-of-Experts model has many internal sub-networks called experts. For each input token, the model uses a router (a learned routing mechanism) to decide which experts should be consulted.

Here’s the key practical consequence:

• The model may contain a huge number of parameters overall (975B), but
• only a smaller subset is used per token (41B “active”).

That sparsity can make a large-capacity model cheaper per generated token than a fully dense model of the same total size.

Inkling’s model card describes a decoder-only transformer with a sparse MoE feed-forward backbone: each token is routed to 6 of 256 experts, plus 2 shared experts active on every token. (huggingface.co)

So when you see numbers like “975B total, 41B active,” it’s not marketing math—it’s an architectural promise about compute efficiency.

One million tokens: what a bigger context window really buys you

Inkling supports a context window of up to 1M tokens. A context window is the amount of information the model can consider at once—think “the stuff it reads before it writes the next response.”

Going from, say, 32K tokens to 1M tokens isn’t just “more space.” It changes the shape of downstream systems:

• You can include longer documents and multi-turn histories without aggressive summarization.
• You can support agentic workflows where tool results accumulate and need to stay grounded.
• You can do retrieval-augmented generation (RAG) where the retrieved evidence set is large and heterogeneous.

In practice, the best systems don’t just shove everything into context; they manage it. But the availability of a huge window gives you more room to build that management layer.

Multimodal reasoning isn’t bolted on

Inkling “reasons natively” over text, images, and audio. In plain terms: it can take those inputs directly and generate text outputs that reflect them.

The model card’s architecture description highlights how modalities are unified: images and video are handled through a hierarchical patch encoder, audio is handled via discrete token encoding, and all modalities are projected into a shared hidden space processed jointly by the decoder. (huggingface.co)

That shared representation matters for customization. If a model treats images and audio as first-class inputs, then fine-tuning can adjust how those modalities interact with instructions, tool use, and formatting rules.

The controllable “thinking effort” idea

One of the sneakiest problems in LLM deployment is cost: more thinking (more generated tokens, more internal steps, more tool calls) tends to improve answers—until it doesn’t justify the latency.

Inkling introduces controllable thinking effort. The blog explains that the effort level can be set during rollouts by changing the system message and adjusting the per-token cost, teaching the model to use different token budgets depending on the requested effort. (thinkingmachines.ai)

This is a powerful mental model:

• You aren’t limited to “fast mode” or “slow mode” as a deployment hack.
• Instead, the model learns a relationship between the instruction context and an efficiency/performance trade-off.

For products built around iteration—where users and systems keep refining outputs—being able to dial effort is like having a dimmer switch rather than a binary on/off.

Fine-tuning with Tinker: LoRA, adapters, and why it matters

Tinker is a training API for fine-tuning. The Tinker documentation frames it as letting developers write loops locally while Tinker runs the GPUs remotely. (tinker-docs.thinkingmachines.ai)

Tinker’s headline for practical customization is LoRA fine-tuning.

What is LoRA (without the mystery)?

LoRA stands for Low-Rank Adaptation. The basic idea is:

• Instead of updating the entire giant parameter set during fine-tuning,
• you learn small additional weight “adapters” that modify the model’s behavior.

“Low-rank” means those adapters have fewer degrees of freedom than full updates. In human terms: you’re teaching the model a new habit without rewriting the whole brain.

This can dramatically reduce training cost and make iteration faster—especially important when you’re running many experiments to find the right recipe.

A full self-finetuning loop (the lipogram demo)

The release doesn’t just say “fine-tune it.” It demonstrates a loop where the model helps fine-tune itself.

The showcased example is delightfully constrained: the model is instructed to become a lipogram assistant, meaning it should never use the letter “e” (or “E”) in its responses.

That target behavior is difficult to achieve reliably through prompting alone, because language generation can accidentally include banned characters. So the system constructs an objective with explicit scoring:

# Lipogram: no 'e' or 'E' in any output.
OBJECTIVE = "A lipogram model that avoids using the letter e in all answers."

def score(prompt, answer) -> float:
    if 'e' in answer or 'E' in answer:
        return 0.0
    return 10.0

Then the pipeline proceeds through the same phases you would expect in a real fine-tuning workflow:

1. Define the objective (what behavior wins).
2. Generate a training dataset and/or synthetic evaluations aligned with that objective.
3. Fine-tune the base model.
4. Evaluate improvements against the original.
5. Switch weights to the improved checkpoint.

Inkling’s blog description shows exactly that choreography: Inkling writes a fine-tuning job, runs it on Tinker, evaluates the result against the base model, and stages an updated checkpoint back into the runtime. (thinkingmachines.ai)

Why this matters beyond the party trick

“Ban the letter e” sounds like a toy. But the engineering pattern is real:

• Constrained objectives are how you make progress measurable.
• Evaluation closes the loop so you don’t confuse “looks better” with “is better.”
• Self-generated training plans are a way to explore objectives faster—especially when the objective can be scored.

One question that shows up in developer discussions is: What does it mean for a model to think in controllable effort while also improving itself through fine-tuning loops? Inkling’s release tries to make that connection practical: the same platform that runs inference-style interactions also supports iterative training workflows.

Inkling-Small: customization for lower cost and latency

Inkling-Small is previewed alongside Inkling, described as a model with 12B active parameters and a similar training recipe aimed at strong performance with lower cost and latency. (thinkingmachines.ai)

From a customization standpoint, that matters because many teams don’t start with the biggest model due to deployment constraints. A smaller sibling lets you prototype behavior and fine-tuning recipes before scaling up.

Closing thoughts: open weights isn’t just access—it’s a workflow

Open-weights releases are sometimes treated like giant downloads with vague future promise.

Inkling feels closer to a workflow announcement: architecture optimized for efficiency (MoE), breadth for multimodal adaptation, controllable thinking effort for cost-aware use, and a training stack (Tinker) meant to turn experiments into updated weights.

The real shift isn’t that the model is open.

It’s that the development loop becomes tighter: define behavior, evaluate it, retrain, and iterate—potentially even letting the model help draft parts of that loop.

Notes & sources

• Inkling release specs (MoE parameters, context window, pretraining scale, controllable thinking effort, and self-finetuning demonstration) (thinkingmachines.ai)
• Inkling model card architecture details (router/expert routing and modality handling) (huggingface.co)
• Tinker overview and LoRA fine-tuning positioning (tinker-docs.thinkingmachines.ai)