Moonshot AI publishes the Kimi K3 weights: 2.8 trillion parameters, licence, requirements and benchmarks

Kimi K3 is a natively multimodal Mixture-of-Experts model with:

• 2.8 trillion total parameters,
• 104 billion parameters activated while generating each token,
• 896 experts, of which 16 are selected,
• a context window of 1,048,576 tokens,
• support for text, images and, according to the API documentation, video,
• a repository size of approximately 1.56 TB.^[2][3]

Moonshot AI describes Kimi K3 as an open-source model. In the strict sense used by the Open Source Initiative, however, open-weight is the safer term. The final parameters, code and documentation have been published, but Kimi K3 uses a custom licence containing additional conditions for some commercial uses. Availability of the weights also does not by itself provide the full transparency of the training process and data required by the Open Source AI Definition.^[4][5][6]

The main conclusion: Kimi K3 is genuinely available for download, modification, fine-tuning and self-hosting, but it is not a model that an average company will run on one GPU server. Publishing the weights creates important research and infrastructure opportunities, while the model’s scale and licence terms require careful analysis before production deployment.

All parameters, prices, licence terms and availability information were verified on 27 July 2026.

TL;DR

Question	Answer
What happened on 27 July?	Full weights, repository, licence and technical report were published
Did the model itself launch today?	No, the model and API were already available
Is Kimi K3 open source?	Moonshot uses that term, but open-weight under a custom licence is more precise
How many parameters does it have?	2.8T total, 104B active
What is the architecture?	MoE, KDA, Gated MLA, AttnRes and Stable LatentMoE
How many experts are there?	896, with 16 selected per token, plus 2 shared experts
What is the context length?	1,048,576 tokens
How large are the files?	Approximately 1.56 TB
How many primary weight shards are there?	96 Safetensors files
Can it be run locally?	Technically yes, but not on a normal computer or single GPU
What does the vendor recommend?	Supernode configurations with at least 64 accelerators
Is commercial use allowed?	Yes, subject to the Kimi K3 License
How much does the official API cost?	$0.30/MTok cache hit, $3/MTok cache miss, $15/MTok output
Can reasoning be disabled?	No, K3 always uses reasoning
Which reasoning levels are supported?	low, high, max, with max as the default
Are all benchmarks independent?	No, part of the results and configurations come from Moonshot AI

1. What exactly was published?

The official moonshotai/Kimi-K3 repository appeared on Hugging Face with:

• full weights,
• the model configuration,
• code required to load the model and process inputs,
• the tokenizer and processor files,
• examples for Transformers, vLLM and SGLang,
• a model card,
• the custom Kimi K3 License.^[2]

The official GitHub repository also contains:

• project code and documentation,
• the k3_tech_report.pdf technical report,
• deployment instructions,
• an architecture and evaluation description.^[3][7]

The weight repository is approximately 1.56 TB. The primary parameters are divided into 96 Safetensors files, named from:

model-00001-of-000096.safetensors

to:

model-00096-of-000096.safetensors

Most shards are approximately 16.6–17 GB.^[8]

This is not a promise of a future release. The weights are already present and available for download.

2. Open source or open-weight?

This is the most important terminology issue surrounding the release.

Moonshot AI uses terms including:

• “open model”,
• “open-source model”,
• “Open Frontier Weights”.

The Hugging Face model card explicitly calls Kimi K3 open-weight.^[2]

What are open weights?

Weights are the final parameters learned during training. Publishing them makes it possible to:

• run the model outside the vendor’s infrastructure,
• fine-tune it,
• create quantised versions,
• analyse model behaviour,
• build custom inference servers,
• integrate the model without sending prompts to the official API.

It does not automatically make the complete model-development process reproducible.

Why does OSI distinguish open weights from Open Source AI?

The Open Source Initiative explains that publishing final weights alone does not provide complete access to:

• the data or sufficiently detailed information about training data,
• all code used to prepare that data,
• the full training configuration,
• the components required to reproduce a substantially equivalent system.^[5][6]

The Open Source AI Definition requires the freedom to:

1. use,
2. study,
3. modify,
4. share,

as well as access to the preferred form needed to make meaningful modifications to the system.^[6]

Is the Kimi K3 licence an OSI-approved licence?

The repository uses a custom Kimi K3 License, not a standard OSI-approved licence such as Apache-2.0 or MIT.

The licence grants broad rights to:

• use,
• copy,
• modify,
• publish,
• distribute,
• sublicense,
• sell,
• deploy,
• fine-tune,
• create derivative works.^[4]

It also introduces additional conditions for certain commercial entities. For production publishing, the safest wording is therefore:

Kimi K3 is an open-weight model released under the custom Kimi K3 License.

That does not mean the model is “closed”. It means the open-source label carries important legal and technical qualifications in this case.

3. Key Kimi K3 parameters

Parameter	Kimi K3
Architecture type	Mixture-of-Experts
Total parameters	2.8 trillion
Activated parameters	104 billion
Number of layers	93
Dense layers	1
Attention layers	69 KDA + 24 Gated MLA
Number of experts	896
Experts selected per token	16
Shared experts	2
Vocabulary size	160,000
Context	1,048,576 tokens
Image encoder	MoonViT-V2
Vision encoder parameters	401 million
Weights	MXFP4
Activations	MXFP8
Modalities in the model card	text and image
Additional modality in the official API	video
Repository size	approximately 1.56 TB
Number of Safetensors shards	96

The architectural values come from the official model card.^[2]

2.8 trillion does not mean 2.8 trillion active parameters

Kimi K3 is an MoE model. It does not use every expert simultaneously when generating one token.

The router selects 16 out of 896 experts, and the documentation lists 104 billion activated parameters. This provides greater capacity without the identical compute cost of a dense 2.8T-parameter model.

It does not mean hardware costs are comparable to a typical 100B model. All weights still have to be stored and distributed appropriately across the accelerators.

4. KDA, AttnRes and Stable LatentMoE

Kimi K3 is not merely a larger version of Kimi K2. Moonshot AI describes several architectural changes.

Kimi Delta Attention

KDA is a hybrid linear-attention mechanism designed to scale long sequences more efficiently.

The model includes:

• 69 KDA layers,
• 24 Gated MLA layers.^[2]

Linear attention is intended to reduce some of the cost of conventional full attention at long context lengths. It does not make a million-token context inexpensive, nor should every task use the full window.

Attention Residuals

AttnRes changes how representations are passed between layers. According to the vendor, it selectively retrieves information from different depths rather than only accumulating it uniformly.^[1]

Stable LatentMoE

Stable LatentMoE allows the number of experts to scale while activating 16 out of 896 experts. Moonshot AI says the combination of architecture, training and data produces an approximately 2.5× improvement in overall scaling efficiency compared with Kimi K2.^[1][2]

This is a vendor claim. It should not be interpreted as an API that is 2.5× faster, 2.5× cheaper or 2.5× better on every task.

Native MXFP4

Kimi K3 was trained with quantisation in mind from the supervised fine-tuning stage:

MXFP4 for weights
MXFP8 for activations

The goal is to reduce memory requirements and make deployment possible on more hardware platforms.^[2]

Even with quantisation, the repository is still approximately 1.56 TB.

5. Can Kimi K3 be run locally?

Yes, but the word “locally” can be misleading.

The model can be hosted in an organisation’s own infrastructure, but it is not intended for a typical:

• laptop,
• workstation with a consumer graphics card,
• single server with one or a few GPUs,
• small home lab.

Moonshot AI recommends supernode configurations with at least 64 accelerators. The reason is not only the weights, but also:

• memory for the KV cache,
• the million-token context,
• communication between experts,
• expert parallelism,
• network bandwidth between devices,
• prefix caching,
• runtime memory headroom.^[1]

Theoretical memory for the weights alone

The repository already contains quantised weights and is approximately 1.56 TB. Additional memory is required for:

• framework overhead,
• caches,
• activations,
• communication buffers,
• the operating system,
• concurrency headroom.

Simply dividing 1.56 TB by the memory of one card does not produce a production-ready configuration.

Recommended engines

The official model card lists:

• vLLM,
• SGLang,
• TokenSpeed.^[2]

Hugging Face also shows basic Transformers and Docker Model Runner examples. The existence of a simple command:

vllm serve "moonshotai/Kimi-K3"

does not mean the model will run on any computer. The framework still needs infrastructure capable of storing and executing the complete model.

Who may benefit from self-hosting?

• hyperscalers and inference providers,
• research laboratories,
• large enterprises with an existing AI cluster,
• organisations processing exceptionally sensitive data,
• companies creating custom fine-tunes and quantisations,
• entities building inference services at scale.

For most teams, the official API or a certified provider will be more economical.

6. What does the licence permit?

The Kimi K3 License is broad, but not unconditional.

It permits free use of the model to:

• use,
• copy,
• modify,
• merge,
• publish and distribute,
• sublicense,
• sell copies,
• run and deploy,
• fine-tune,
• create derivative solutions.^[4]

The copyright notice and licence text must be retained, and applicable law must be followed.

Model as a Service condition

The licence defines Model as a Service as providing a third party with inference or fine-tuning in a way that gives that party material control over inputs, parameters or training data.

If a licensee or its affiliates:

1. operate a Model as a Service business,
2. have combined revenue exceeding $20 million in any consecutive 12-month period,

they must enter into a separate agreement with Moonshot AI before commercially using the model or derivative works.^[4]

This is not a threshold for revenue generated solely by Kimi K3. The licence refers to the combined revenue of the licensee and its affiliates.

Requirement to display the Kimi K3 name

If the model or a derivative solution is used in a commercial product or service with:

• more than 100 million monthly active users, or
• more than $20 million in monthly revenue,

the name “Kimi K3” must be prominently displayed in the user interface.^[4]

Exceptions

The Model as a Service and visible-attribution conditions do not apply:

• to internal use that does not expose the model, outputs or capabilities to third parties,
• when using official Moonshot AI products,
• when using certified inference partners.^[4]

What should a company determine?

Before production use, document:

• whether the system is internal only,
• whether a customer receives control over inference or fine-tuning,
• the combined group revenue,
• whether the product exceeds the MAU or monthly-revenue threshold,
• whether Kimi K3 attribution is required,
• whether a separate agreement is needed.

This article is not legal advice. In an enterprise, the legal department should approve the licence interpretation.

7. What was not published?

The release is significant, but it does not mean the complete model-development process has been disclosed.

The official materials provide:

• final weights,
• part of the code,
• the architecture configuration,
• inference and processor code,
• a technical description,
• evaluation results.

One should not conclude from this that the full training dataset or every detail required for an independent team to reproduce Kimi K3 from scratch has been released.

The model is therefore far more open than a closed API, but it does not provide full training reproducibility in the OSI sense.^[5][6]

8. Kimi K3 API and pricing

The model is available under the identifier:

kimi-k3

The official API uses an interface compatible with OpenAI Chat Completions.

Pricing

Token type	Price per 1 million tokens
Input with cache hit	$0.30
Input with cache miss	$3.00
Output	$15.00

The prices come from Moonshot AI’s official material and may exclude applicable taxes.^[1]

The vendor says its infrastructure achieves a cache hit rate above 90% in coding workloads. This is a statistic for the official API, not a guarantee for every customer or prompt.^[1]

Top-up requirement

Kimi K3 API access is unlocked after a successful account top-up of at least $1. Account tier and limits depend on cumulative top-ups.^[9]

9. First Python request

import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.ai/v1",
)

response = client.chat.completions.create(
    model="kimi-k3",
    reasoning_effort="high",
    max_completion_tokens=8_192,
    messages=[
        {
            "role": "user",
            "content": (
                "Analyse the project architecture and prepare "
                "a secure migration plan."
            ),
        }
    ],
)

message = response.choices[0].message
print(message.content)

The API is compatible with the OpenAI client, but not every parameter behaves identically to other models.

cURL

curl https://api.moonshot.ai/v1/chat/completions \
  --header "Authorization: Bearer $MOONSHOT_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "model": "kimi-k3",
    "reasoning_effort": "high",
    "max_completion_tokens": 8192,
    "messages": [
      {
        "role": "user",
        "content": "Analyse this problem and propose a solution."
      }
    ]
  }'

10. Reasoning is always enabled

Kimi K3 always operates in reasoning mode. There is no parameter that completely disables it.^[9][10]

Three levels are available:

low
high
max

The default is:

max

For much production traffic, it is sensible to begin with low or high, reserving max for the most difficult tasks.

reasoning_content

A response may separately contain:

• reasoning_content,
• final content.

During streaming, both fields are returned as separate chunks.^[9][10]

Do not automatically:

• display reasoning to the user,
• store it without limits,
• send it to logging systems containing personal data,
• treat it as a reliable audit of the decision process.

Preserved Thinking

In multi-turn conversations and tool-calling workflows, the next request must include the complete assistant message:

• reasoning_content,
• content,
• tool_calls.

Keeping only the final content is not sufficient.^[10]

Historical reasoning consumes context and is billed in tokens. It can materially increase the cost of long sessions.

11. API limits and differences

The official documentation lists several important limitations.^[9]

Maximum output

default: 131,072 tokens
maximum: 1,048,576 tokens

The technical maximum does not mean such a long generation will be inexpensive, fast or practical.

Fixed generation parameters

Kimi K3 uses fixed values:

temperature = 1.0
top_p = 0.95
n = 1
presence_penalty = 0
frequency_penalty = 0

The documentation recommends omitting them from requests.

Images and video

Public image URLs are not supported in the official K3 API. Use:

• base64 data,
• an ms://<file-id> file identifier.

The documentation also demonstrates sending video files through Moonshot’s file system.^[9]

Web search

The official web-search feature is being updated, and the documentation currently advises against using it in production workflows.^[9]

This matters for research agents: the model itself should not be treated as a source of current information without an independent search and citation system.

12. Million-token context and cache

Kimi K3 supports a context length of:

1,048,576 tokens

This can help with:

• large repositories,
• enterprise documentation,
• analysis of many files,
• long-running agent sessions,
• multistage research.

Automatic cache

Prefix caching operates automatically. No cache identifier or TTL has to be provided.

A previous prompt must exceed 256 tokens before a cache hit can be attempted.^[9]

In practice:

1. keep a long, unchanged prefix,
2. place the variable question at the end,
3. measure actual cache hits,
4. do not assume every subsequent request receives the lower price.

One million tokens does not mean perfect memory

The maximum context capacity does not guarantee:

• finding every relevant line,
• resolving contradictions correctly,
• resistance to prompt injection in documents,
• appropriate prioritisation of content,
• no degradation when irrelevant material is present.

Large-context use still requires:

• source selection,
• indexing,
• access control,
• document segmentation,
• retrieval-accuracy testing.

13. Tool calling and agent workflows

Kimi K3 supports:

• custom tools,
• tool_choice,
• forced tool use,
• structured output with JSON Schema,
• Partial Mode,
• dynamic loading of tool definitions,
• official Formula tools.^[9]

Dynamic tools

A tool definition can be inserted at the appropriate point in the conversation history, so the agent does not need all tools from the beginning.

This can reduce:

• prompt length,
• incorrect tool selection,
• the permission surface,
• the risk of invoking an unnecessary operation.

The server does not store the definition on the client’s behalf. The message must be preserved in later history.

Structured output

K3 can force the final response to comply with JSON Schema:

response_format = {
    "type": "json_schema",
    "json_schema": {
        "name": "finding",
        "strict": True,
        "schema": {
            "type": "object",
            "properties": {
                "severity": {
                    "type": "string",
                    "enum": ["low", "medium", "high", "critical"],
                },
                "summary": {"type": "string"},
            },
            "required": ["severity", "summary"],
            "additionalProperties": False,
        },
    },
}

Parse the final message.content, not reasoning_content.^[9]

14. Kimi Code and coding use cases

Moonshot AI positions Kimi K3 primarily for:

• long coding tasks,
• work with large repositories,
• coordination of terminal tools,
• refactoring,
• frontend work from screenshots,
• GPU kernels, compiler development, CAD and chip design.^[1][2]

The official terminal agent is Kimi Code. It can:

• read and edit files,
• run shell commands,
• search files,
• retrieve web pages,
• plan the next steps from results,
• operate through a TUI,
• integrate with editors through the Agent Client Protocol.^[11]

Installation on macOS or Linux

curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash

Then:

cd /path/to/project
kimi

Within the session, use:

/model

and select Kimi K3.

Permissions

Official materials state that read-only operations may be performed automatically, while file modification and command execution require confirmation in the standard configuration.^[11]

In production, still:

• use a container or sandbox,
• restrict network access,
• do not expose production secrets,
• require review before merge,
• block automatic deployment,
• log changes,
• limit token and time budgets.

15. How should Kimi K3 benchmarks be read?

The model card publishes a broad table covering reasoning, coding, agentic tasks, office work and vision.

Selected officially reported Kimi K3 results at max effort:

Benchmark	Kimi K3 result
GPQA Diamond	93.5
DeepSWE	67.5
ProgramBench	77.8
Terminal-Bench 2.1	88.3
FrontierSWE	81.2
SWE-Marathon	42.0
BrowseComp	91.2
MCPMark-Verified	94.5
OSWorld-Verified	84.8
AutomationBench	30.8

Why can’t this be turned into a simple ranking?

The results use different:

• harnesses,
• reasoning levels,
• agent configurations,
• sources,
• leaderboard dates,
• numbers of runs,
• context-management procedures.

For example, in Agents’ Last Exam:

• Kimi K3 was paired with Kimi Code,
• GPT models used Codex,
• Claude models used Claude Code.^[2]

In some benchmarks, another model’s result comes from an external leaderboard while Kimi K3 is evaluated by the vendor. This is not a perfectly controlled model-to-model comparison.

The vendor itself says K3 does not lead everywhere

Moonshot AI wrote that Kimi K3’s overall performance still trails the strongest proprietary models Claude Fable 5 and GPT-5.6 Sol.^[1]

The table also shows that K3:

• leads on some tests,
• is close to leaders on others,
• loses selected tasks,
• may have a favourable capability-to-cost ratio, but is not unconditionally best.

How should a company test it?

Instead of copying one benchmark:

1. prepare 50–200 real tasks,
2. hide reference answers,
3. use identical tools and limits,
4. compare multiple reasoning levels,
5. measure the cost of the completed task,
6. run each task several times,
7. evaluate tests, diffs and outcomes rather than writing style.

16. Multimodality: text, image and video

The model card lists text and image, while the official API documentation also demonstrates video input.^[2][9]

Use cases include:

• screenshot analysis,
• UI correction,
• chart interpretation,
• coding from visual references,
• screen-recording analysis,
• motion design and video editing.

Moonshot AI presents examples where K3 uses vision for:

• game development,
• frontend work,
• CAD,
• video editing.^[1]

These are vendor demonstrations, not guaranteed results for every project. Production tests should cover:

• reading text in user interfaces,
• precise element localisation,
• consistency across frames,
• input formats,
• cost of large media,
• privacy of images and recordings.

17. Security, privacy and governance

Open weights change the risk model, but do not remove it.

Self-hosting benefits

• data can remain in controlled infrastructure,
• external telemetry can be disabled,
• custom filters and policies are possible,
• the organisation controls the model version,
• network access can be restricted,
• independent security testing is possible.

New responsibilities

• securing the cluster and endpoints,
• tenant isolation,
• abuse monitoring,
• validation of generated code,
• protecting the weights against unauthorised copying,
• runtime updates,
• vulnerability management for vLLM, SGLang and dependencies,
• reasoning and log governance,
• rate limits and circuit breakers.

No independent proof of complete safety

At publication time, the official sources provide architecture, use cases and benchmarks. The materials used for this article did not contain an independent, comprehensive Kimi K3 safety audit comparable to a full vendor system card or extensive third-party red teaming.

That does not mean the model is unsafe. It means regulated deployment should include internal tests for:

• prompt injection,
• data exfiltration,
• jailbreaks,
• harmful code generation,
• hallucinations,
• malicious documents,
• tool actions,
• privilege escalation.

18. Self-hosting or the official API?

Criterion	Self-hosting	Official API
Initial cost	very high	low
Minimum infrastructure	multi-accelerator cluster	no own cluster
Data control	highest	subject to service terms
Updates	organisation’s responsibility	vendor-managed
Fine-tuning	full control	depends on the offer
Scaling	organisation’s responsibility	managed
Cache	own implementation	automatic
Deployment time	long	short
Licence	requires Kimi K3 License analysis	some licence conditions excluded for official products
Economics for a small team	usually poor	usually better

Choose the API when:

• you are initially evaluating the model,
• load is variable,
• you do not own an AI cluster,
• rapid deployment is important,
• you do not plan to modify the weights,
• the data can be processed under the vendor’s terms.

Consider self-hosting when:

• data cannot leave the infrastructure,
• you already have a cluster with a fast interconnect,
• utilisation is sufficiently large and steady,
• fine-tuning is required,
• version and policy control are necessary,
• the team has distributed-inference expertise.

19. Is Kimi K3 worth deploying?

Yes, when:

• you need a very large self-hostable model,
• the required infrastructure already exists,
• you want to research 3T-class models,
• you are building an inference provider,
• native multimodality and long context are needed,
• your workload contains long agentic coding tasks,
• you want to create custom fine-tunes and quantisations.

Not necessarily, when:

• the team has only one GPU server,
• simple queries need low latency,
• a cheaper model’s API is already good enough,
• reasoning must be disabled,
• a standard Apache or MIT licence is required,
• full training-process reproducibility is required,
• there is no team to operate distributed inference.

20. Verdict

Publishing the complete Kimi K3 weights is an important event for the open-model market.

Moonshot AI released a model with:

• 2.8 trillion parameters,
• 104 billion active parameters,
• native multimodality,
• a million-token context,
• an MoE architecture with 896 experts,
• capabilities aimed at coding and long agentic tasks.

Three separate facts must nevertheless be distinguished:

1. Kimi K3 was announced earlier.
2. The full weights and technical materials were published on 27 July.
3. It is an open-weight model under a custom licence, not unambiguously Open Source AI under the OSI definition.

For researchers and inference providers, this is a valuable release. For a typical company, the ability to download the weights does not make deployment economical. A 1.56 TB repository and the recommendation of at least 64 accelerators make Kimi K3 an infrastructure project, not a model installed with one command on an ordinary server.

The sensible strategy is:

First:
POC through the official API

Then:
measure quality, cost, latency and risk

Only afterwards:
analyse self-hosting, licensing and cluster design

Kimi K3 is not automatically the best model for every company. It is, however, one of the most important publicly available open-weight models by scale and may accelerate independent inference, quantisation and research into MoE systems.

21. Pre-deployment checklist

Terminology and licence

• Documentation uses the term open-weight.
• Licence text and copyright are retained.
• The legal department has reviewed the Kimi K3 License.
• It has been determined whether the system is Model as a Service.
• The $20M revenue threshold over 12 months has been checked.
• The 100M MAU threshold has been checked.
• The $20M monthly-revenue threshold has been checked.
• It has been determined whether Kimi K3 must be visible in the UI.
• Internal-only use has been documented.

Infrastructure

• The approximately 1.56 TB size has been verified.
• Download of 96 shards has been planned.
• Downloaded file integrity is checked.
• vLLM, SGLang or TokenSpeed has been selected.
• Sufficient accelerator memory is available.
• Fast interconnects between devices are available.
• Expert parallelism has been planned.
• KV cache for the required context has been estimated.
• GPU, network and memory monitoring has been added.
• Runtime-update procedures exist.

API and agent

• The kimi-k3 model is used.
• The appropriate reasoning_effort is selected.
• The system does not try to disable reasoning.
• Complete reasoning_content history is preserved.
• A reasonable max_completion_tokens value is set.
• Fixed sampling parameters are not sent.
• Images use base64 or ms://.
• Web search is not a critical production dependency.
• Tool calls are validated before execution.
• Structured output is validated against the schema.

Security

• The model runs in a sandbox.
• Tools use least privilege.
• Automatic production access is blocked.
• Secrets do not enter prompts or logs.
• Reasoning is not logged unnecessarily.
• Prompt injection has been tested.
• Malicious documents and images have been tested.
• Cost, duration and tool-call limits exist.
• Destructive actions require human approval.
• Generated code passes tests and review.

Evaluation

• A custom task set has been prepared.
• At least three models are compared.
• An identical harness is used.
• Each task is run several times.
• Total task cost is measured.
• Time to a correct result is measured.
• Code review and refactoring are evaluated.
• Multimodality is evaluated.
• Long-context behaviour is evaluated.
• Hallucinations and citations are checked.

22. Related POLPROG material

• Kimi K3 vs Claude Fable 5
• Kimi K3 vs GPT-5.6 Sol
• AI tools in the POLPROG Knowledge Base
• Will an AI feature pay for itself?