DocMeThis was initially developed for Python. This choice enables precise static analysis of signatures, docstrings, parameters, return values, and code structures. Support for the following languages is planned during 2026: Java, JavaScript, TypeScript, C++, PHP, and Ruby. Sign up for our newsletter to be notified when new languages become available.

No. DocMeThis complements your tests and linters. Tests verify that the code works. Linters verify its form. DocMeThis verifies that the knowledge conveyed by the documentation remains aligned with the code. Actually, it is greatly recommended to run Ruff before DocMeThis.

The CI Check GitHub Action and the components required for its operation are open and published under the MIT license. In addition, we offer strongly preferential pricing for OSS projects — in particular, free access to the first two tiers of our CI Fix and Audit solutions.

DocMeThis is fully compatible with confidential codebases. Depending on the sensitivity level, analysis can be performed through a sovereign cloud, a self-hosted runner, on-site intervention, or even a strictly air-gapped environment. The Audit relies on static analysis: the application does not need to be executed. DocMeThis never stores code provided by the client.

You receive a prioritized report showing documentation coverage, code/doc inconsistencies, debt areas by module, and the corrections to address first, along with the complete list of symbols that need documentation.

The CI Check offer detects documentation drift in CI, commit after commit. The Audit offer provides an overall view of a project’s documentation debt: coverage, critical areas, inconsistencies, and correction priorities.

The CI Check offer is itself MIT-licensed and free without conditions.
The first two tiers of CI Fix are free for open source projects. Preferential pricing applies beyond, on a quote basis.
The first two tiers of Audit are free for open source projects.
The premium Build offer remains paid, with preferential pricing, on a quote basis.

A documentation credit is the unit used by DocMeThis to quantify resource usage. Concretely, documenting a symbol (class, function, etc.) costs 3 credits, and each documentation element (parameter, return value, etc.) within the symbol costs 1 credit. This calculation is justified by the AST complexity.

Examples:
- PR with a function of two parameters and a return value: 3 + 2 + 1 = 6 credits;
- PR with a class, three methods, one of which has four parameters and a raise: 3 + 3×3 + 4 + 1 = 17 credits.

Credits are renewed monthly. If the quota is reached, CI Fix services are suspended with a neutral PR/MR message. You can supplement your subscription with a credit pack of 500 additional credits for €9 (valid 12 months, consumed after monthly credits).

Exceeding the CI Fix quota has no impact on CI Check execution, and does not block the CI, unless explicitly configured.

No, not without validation. CI Check and Audit offers report issues. CI Fix and Build offers suggest documentation corrections, but these must be validated before integration. Validation can be automated, but that remains your choice.

CI Check and CI Fix are designed for incremental maintenance: measuring documentation drift in CI and correcting docstrings as PRs/MRs come in.
CI Check has an evaluation mode that provides a synthetic diagnosis of documentation debt at the scale of an entire project, with some statistics, but this summary cannot replace the detailed diagnosis, prioritization, and list of corrections to be made symbol by symbol, among others, which are the deliverables of our Audit offer.
To catch up with significant documentation debt, CI Fix is generally not suitable: this tool is designed to correct progressively, not to massively generate docstrings on hundreds of symbols. If you need to remove significant documentation debt to start on a solid foundation for incremental maintenance, request a quote for docstring generation via the Build offer.

Of course! Needs vary greatly from one project to another, so the Build offer is designed to adapt to all requests, whether it is simply generating or correcting a project’s docstrings, creating a complete documentation package, or any intermediate level of granularity.

The standard plans cover self-service use of CI Check and CI Fix plans with their monthly quotas. The Enterprise offer adds custom credit limits, integration with other CI environments, custom configuration, and integration and support assistance. It therefore mainly expands the integration and service scope without changing the principle of the checks or validations.

By default, CI Check is diff-first and checks the Python files and symbols affected by the Git range. The catchup mode can nevertheless analyze an entire repository: with --check-mode catchup --git-diff ${EMPTY_TREE}..HEAD, where ${EMPTY_TREE} denotes the empty Git tree, all Python files tracked by Git are considered added and checked. The resulting summary is representative of the entire repository for that run. This remains a Check report and does not replace the detailed deliverables of the Audit offer.

Yes, depending on the selected configuration. An error produces a failure exit code. Warning handling depends on fail_on_warning. Severities can be configured by DMT code, as can visibility settings, symbol types, check mode, and the policy applied when a Git base is unavailable.

No. CI Check statically analyzes Python files, their signatures, and their docstrings. It does not import or execute your application and does not run your tests. It only runs the Git commands needed to resolve the diff and its base. Project tests remain the responsibility of your own CI.

A range explicitly passed with --git-diff takes priority. Otherwise, on a pull request, Check uses the common ancestor with the base branch. On a linear push, it uses GITHUB_BEFORE_SHA..GITHUB_SHA when the previous SHA is an ancestor of the new one. After a force-push, rebase, amend, or squash, it first uses a configured reference branch, then the latest available common ancestor. If no reliable base exists, the configuration chooses between failing, partially analyzing the last commit, or returning an inconclusive non-blocking result. The strategy, completeness, and reason are reported in the JSON report.

The reference Check workflow only uses contents: read. It does not need to write to the repository, an LLM key, or a Gateway key. A Fix workflow that pushes a correction requires contents: write to create and push a correction branch. It also uses a Fix distribution token, a Gateway API key, and the selected LLM provider’s secret, for example OPENROUTER_API_KEY. An OIDC context additionally requires id-token: write: this is required for some OSS use cases or reruns, but not for the standard paid mode with an API key alone.

CI Fix reads the Check report, selects diagnostics it knows how to fix, generates the required docstrings, and validates each candidate with the deterministic verifier and the rendering safety gate. By default, the CLI applies patches and creates a commit. --dry-run previews fixes, --no-commit applies patches without a commit, and --push pushes the commit upstream. A workflow can choose to create a dedicated branch first, such as docmethis-fix/..., so corrections can be submitted for review.

The commercial quota is the plan’s monthly credits plus any packs. Each request atomically reserves the number of credits calculated by Fix. The request must not exceed the Gateway’s configurable technical hard cap, independent of the plan. Exceeding the hard cap produces REQUEST_INVALID, while insufficient quota produces QUOTA_EXHAUSTED. If a correction fails fully or partially, the reservation is released; on complete success, it is consumed. CI Check remains independent of the CI Fix quota.

DocMeThis is fully compatible with confidential codebases. Depending on the sensitivity level, analysis can be performed through a sovereign cloud, a self-hosted runner, on-site intervention, or even a strictly air-gapped environment. The Audit relies on static analysis: the application does not need to be executed. DocMeThis never stores code provided by the client.

Not necessarily. The CI Check and CI Fix offers run in your environment, and CI Fix relies on your own LLM provider. The code therefore does not transit through our servers. As for the Audit and Build offers, we can also run them from your infrastructure, depending on the required confidentiality level.
In all cases, we never retain code entrusted to us, and we never use the data for any purpose other than creating the deliverables subscribed to by the client.

Given their mode of operation, the attack surface of our services seems relatively low in terms of risks. In any case, we do our best to follow best practices in terms of cybersecurity, and an external security review is on our roadmap.

Subscription management and billing are handled by Chargebee. Depending on the payment method selected, payment data is then processed by Stripe or PayPal through the Chargebee checkout. DocMeThis does not store any banking information on its own servers.

Subscription management, billing, and quotas are handled by Chargebee, a specialized billing provider. DocMeThis minimizes the storage of customer data on its own servers: we only retain information necessary for the service’s operation, such as account identification, access rights, essential technical information, and elements required for customer support.

CI Check runs its analysis in your runner and does not send your code to DocMeThis or an LLM service. It may write a local cache and reports, which your workflow can then retain as artifacts. CI Fix sends the prompts and context needed to the LLM provider configured in your project. For confidential code, using a local or self-hosted provider is strongly recommended. Data retention and usage rules depend on the LLM provider you choose. Gateway does not receive the code manifest: no files, symbols, paths, or code hashes.

These are two different notions.

LLM inference relies on probabilistic calculations and is therefore generally not reproducible. Generation is said to be deterministic when, for the same input, the model produces the same output. Some inference engines now allow, for certain models, guaranteeing this determinism.

Note: model providers are generally not configured to offer this feature. This is why our CI Fix offer is not presented as deterministic at this time. Only the Build offer can be, when we control the inference engine and its configuration.

Generation is constrained when the model’s generation space is deliberately limited: precise prompt, context from the AST, restricted output format, validation and rejection of non-conforming outputs, etc.

These constraints do not make the model infallible, but they greatly reduce the risk of hallucination and make it possible to detect, reject, or correct outputs that do not respect observable facts in the code.

No, only the Build offer includes inference: our infrastructure does not currently allow us to provide a continuous inference service. The CI Fix service studies the AST context, generates a dedicated prompt for each element to document, launches the LLM request, and verifies the validity of the generated docstring. It therefore does not directly consume tokens — inference is delegated to the model of your choice, to configure in GitHub or GitLab. This system allows great flexibility: you can use your Claude or ChatGPT subscription, deploy your own model, or use a third-party API. We recommend using a lightweight model with good development performance.

The documentation audit and drift detection rely on static analysis, with no AI generation. For docstring generation offers, AI usage terms depend on the confidentiality level you choose.

DocMeThis can use almost any generative AI model. For CI-based documentation generation, you can choose the model you prefer. For premium documentation generation, which is heavier to process, we have tested and selected several models we are used to working with, but the final model choice remains yours.

Yes. DocMeThis does not depend on a specific AI provider and was designed to connect to almost any provider. Whether you want to use your Anthropic Claude subscription, OpenAI ChatGPT, an API of your choice, or even a locally deployed model, almost everything is possible.

The current CI Check package runtime requires Python 3.12 or later. This constraint concerns Check execution, not necessarily the Python version targeted by the analyzed repository: older Python 3.x code can be analyzed when it remains compatible with the parser and dependencies used. The current scope covers .py, .pyw, and .pyi files, as well as NumPy-style docstrings. Support for other languages and styles, especially Google and reStructuredText/Sphinx, is among our development priorities.