Usage: scc [flags] [files or directories]

Examples: Count the current directory: scc

Count a specific folder or file: scc myproject/ scc main.go

Count several paths at once: scc src/ docs/ README.md

Show a per-file breakdown instead of the per-language summary: scc --by-file

Output as CSV or JSON (e.g. for further processing): scc --format csv scc --format json -o counts.json

Count an unrecognised extension as a known language: scc --count-as jsp:html

Count files matching a path pattern as a new category (glob by default): scc --count-as-pattern '*_spec.rb:Ruby Spec:Ruby'

Generate a self-contained HTML infographic report: scc --report scc --report=out.html --report-title "myrepo" --report-skip cocomo

Use a project config file (./.sccconfig) or a global one (precedence: global < project < CLI): export SCC_CONFIG_PATH=~/.sccconfig scc --config team.sccconfig

Tune the COCOMO cost estimate, or turn it off (see https://en.wikipedia.org/wiki/COCOMO): scc --avg-wage 75000 --cocomo-project-type semi-detached scc --no-cocomo

Flags: --avg-wage int average wage value used for basic COCOMO calculation (default 56286) --binary disable binary file detection --buckets int time-bucket resolution for the git timeline reports (default 60) --by-author render the author rollup report (bus factor and last-toucher attribution over recent git history) --by-file display output for every file -m, --character calculate max and mean characters per line --ci enable CI output settings where stdout is ASCII --cocomo-project-type string change COCOMO model type [organic, semi-detached, embedded, "custom,1,1,1,1"] (default "organic") --cognitive calculate cognitive (nesting-weighted) complexity --config string load this file as the global config source; overrides SCC_CONFIG_PATH, honored even with --no-config --cost-comparison show both COCOMO and LOCOMO estimates side by side --count-as string count extension as language [e.g. jsp:htm,chead:"C Header" maps extension jsp to html and chead to C Header] --count-as-pattern stringArray count files matching a path pattern as a new named category backed by a base language [repeatable; pattern is glob by default, prefix with re: for regex; e.g. *_spec.rb:"Ruby Spec":Ruby or re:\.test\.js$:"JavaScript Tests":JavaScript] --count-ignore set to allow .gitignore and .ignore files to be counted --count-unsupported count files with an unrecognised language under an "Unknown" category as plain text --coupling render the change-coupling report (file pairs that change together over recent git history) --coupling-for string blast-radius view: given a file path, show what tends to change with it over recent git history --coupling-weighted weight coupling by file complexity so pairs of complex files rank above generated/data-file churn (implies --coupling) --currency-symbol string set currency symbol (default "$") --debug enable debug output --depth int commit window size for git history reports; 0 means entire history (large repos may be slow) (default 1000) --directory-walker-job-workers int controls the maximum number of workers which will walk the directory tree (default 8) -a, --dryness calculate the DRYness of the project (implies --uloc) --eaf float the effort adjustment factor derived from the cost drivers (1.0 if rated nominal) (default 1) --exclude-dir strings directories to exclude (default [.git,.hg,.svn]) -x, --exclude-ext strings ignore file extensions (overrides include-ext) [comma separated list: e.g. go,java,js] -n, --exclude-file strings ignore files with matching names (default [package-lock.json,Cargo.lock,yarn.lock,pubspec.lock,Podfile.lock,pnpm-lock.yaml]) --exp-per-language-counters experimental, may change or be removed: count with the scanner written for the file's language where there is one, currently C, C Header and Java --file-gc-count int number of files to parse before turning the GC on (default 10000) --file-list-job-workers int number of goroutine workers that turn a walked path into a job to be counted (default 8) --file-list-queue-size int the size of the queue of files found and ready to be read into memory (default 8) --file-process-job-workers int number of goroutine workers that process files collecting stats (default 8) --file-summary-job-queue-size int the size of the queue used to hold processed file statistics before formatting (default 8) --find-root-config discover the project .sccconfig by walking up to the repository root instead of using ./.sccconfig -f, --format string set output format [tabular, wide, json, json2, csv, csv-stream, cloc-yaml, html, html-table, sql, sql-insert, openmetrics] (default "tabular") --format-multi string have multiple format output overriding --format [e.g. tabular:stdout,csv:file.csv,json:file.json] --gen identify generated files --generated-markers strings string markers in head of generated files (default [do not edit,]) -h, --help help for scc --hotspots render the hotspots report (files ranked by complexity × change frequency over recent git history) --ignore-file stringArray path to an additional gitignore-format ignore file, applied from the scan root; repeat to add more, later files and any in-tree ignore files take precedence -i, --include-ext strings limit to file extensions [comma separated list: e.g. go,java,js] --include-symlinks if set will count symlink files -l, --languages print supported languages and extensions --large-byte-count int number of bytes a file can contain before being removed from output (default 1000000) --large-line-count int number of lines a file can contain before being removed from output (default 40000) --locomo enable LOCOMO (LLM Output COst MOdel) cost estimation --locomo-config string LOCOMO power-user config "tokensPerLine,inputPerLine,complexityWeight,iterations,iterationWeight" --locomo-cycles float override estimated LLM iteration cycles (default: calculated from complexity) --locomo-input-price float LOCOMO cost per 1M input tokens in dollars (overrides preset) --locomo-output-price float LOCOMO cost per 1M output tokens in dollars (overrides preset) --locomo-preset string LOCOMO model preset [large, medium, small, local] (default "medium") --locomo-review float human review minutes per line of code for LOCOMO estimate (default 0.01) --locomo-tps float LOCOMO output tokens per second (overrides preset) --mcp start as an MCP (Model Context Protocol) server over stdio --min identify minified files -z, --min-gen identify minified or generated files --min-gen-line-length int number of bytes per average line for file to be considered minified or generated (default 255) --no-cocomo remove COCOMO calculation output -c, --no-complexity skip calculation of code complexity --no-config disable auto-discovery of the SCC_CONFIG_PATH global and the project ./.sccconfig config -d, --no-duplicates remove duplicate files from stats and output --no-fold-authors disable the name+email-domain identity folding fallback for git author reports (mailmap still applied) --no-gen ignore generated files in output (implies --gen) --no-gitignore disables .gitignore file logic --no-gitmodule disables .gitmodules file logic --no-hborder remove horizontal borders between sections --no-ignore disables .ignore file logic --no-large ignore files over certain byte and line size set by large-line-count and large-byte-count --no-min ignore minified files in output (implies --min) --no-min-gen ignore minified or generated files in output (implies --min-gen) --no-scc-ignore disables .sccignore file logic --no-size remove size calculation output -M, --not-match stringArray ignore files and directories matching regular expression -o, --output string output filename (default stdout) --overhead float set the overhead multiplier for corporate overhead (facilities, equipment, accounting, etc.) (default 2.4) -p, --percent include percentage values in output --remap-all string inspect every file and remap by checking for a string and remapping the language [e.g. "-- C++ --":"C Header"] --remap-unknown string inspect files of unknown type and remap by checking for a string and remapping the language [e.g. "-- C++ --":"C Header"] --report string[="scc-report.html"] write a self-contained HTML report; bare flag writes scc-report.html and prompts before overwriting, --report=path/out.html overwrites silently --report-skip string comma-separated sections to omit (cocomo,locomo,hotspots,coupling,authors,timeline,files,uloc,linelength,card) --report-title string override the repo name shown in the report banner --size-unit string set size unit [si, binary, mixed, xkcd-kb, xkcd-kelly, xkcd-imaginary, xkcd-intel, xkcd-drive, xkcd-bakers] (default "si") --sloccount-format print a more SLOCCount like COCOMO calculation -s, --sort string column to sort by [files, name, lines, blanks, code, comments, complexity] (default "files") --sql-project string use supplied name as the project identifier for the current run. Only valid with the --format sql or sql-insert option --timeline render an over-time view of recent git history; with --by-author runs the author timeline, alone runs the languages timeline -t, --trace enable trace output (not recommended when processing multiple files) -u, --uloc calculate the number of unique lines of code (ULOC) for the project -v, --verbose verbose output --version version for scc -w, --wide wider output with additional statistics (implies --complexity)

Output should look something like the below for the redis project

Note that you don't have to specify the directory you want to run against. Running scc will assume you want to run against the current directory.

You can also run against multiple files or directories scc directory1 directory2 file1 file2 with the results aggregated in the output.

Since scc writes to standard output, there are many ways to easily share the results. For example, using netcat
and one of many pastebins gives a public URL:

### Ignore Files

scc supports .ignore files inside directories that it scans. This is similar to how ripgrep, ag and tokei work. 
.ignore files are 100% the same as .gitignore files with the same syntax, and as such scc will ignore files and 
directories listed in them. You can add .ignore files to ignore things like vendored dependency checked in files and 
such. The idea is allowing you to add a file or folder to git and have ignored in the count.

It also supports its own ignore file .sccignore if you want scc to ignore things while having ripgrep, ag, tokei 
and others support them.

You can also supply additional ignore files from outside the scanned tree with --ignore-file. The file uses the 
same gitignore syntax and its patterns are anchored at the scan root (so /build matches only the top-level build). 
This is handy for applying a shared ruleset such as a .dockerignore or a personal global ignore:

The flag can be repeated and order matters: a later file can re-include something an earlier one ignored (via a ! 
negation), and any .gitignore, .ignore or .sccignore discovered inside the scanned tree takes precedence over 
everything supplied with --ignore-file.

If you want to apply your global git excludes file, point --ignore-file at it directly (for example 
--ignore-file ~/.config/git/ignore). scc deliberately does not shell out to git to discover it for you, but you 
can make it automatic by putting the flag in a .sccconfig configuration file and pointing the SCC_CONFIG_PATH environment 
variable at it, so every run picks it up without typing:

~/.config/scc/global.sccconfig

### Configuration Files

scc can read default flags from a configuration file to avoid creating shell aliases. 
The format is an opts-list in the style of ripgrep and bat: the file is simply a list of the same command-line flags 
you would otherwise type, and anything valid on the command line is valid in the file, with the exception
of output flags.

Format rules:
One flag per line is the recommended style, but multiple whitespace-separated tokens per line are allowed (--exclude-dir vendor).

Lines use the normal -- prefix, e.g. --no-cocomo.

# begins a comment. Whole-line and inline trailing comments are stripped.

Blank lines are ignored.
Tokenization is quote-aware, so both --exclude-dir vendor and --count-as 'jsp:html' work. Quotes (single or double) are the only grouping mechanism; to include a literal quote, switch quote style (--count-as "a'b").

Backslash is an ordinary literal, not an escape character, so a Windows path such as --exclude-dir C:\build\out survives verbatim.

A line whose first token does not start with - (a bare positional such as src/) is skipped with a warning, so a config file cannot inject extra count targets.

Example .sccconfig:

count the way I like it

#### Sources and discovery
There are two configuration tiers:
Global — there is no fixed default location and no per-run home-directory stat. The global source is consulted only when set explicitly via the SCC_CONFIG_PATH environment variable or the --config <path> flag. --config which overrides SCC_CONFIG_PATH.

Project — a file named .sccconfig in the current working directory (./.sccconfig), found with a single stat and no walk-up. cd project && scc picks up project/.sccconfig; running scc from a subdirectory does not pick up an ancestor's .sccconfig. Path arguments do not move the anchor — scc ./project still reads ./.sccconfig, not ./project/.sccconfig.

To read the repository root's .sccconfig from a subdirectory, pass --find-root-config, which walks back from the current directory to the git/hg root. It is off by default and affects config discovery only - it changes which .sccconfig is read, not which directory is counted. Outside a repository it degrades to ./.sccconfig.
Precedence
Lowest to highest, later wins: global config < project config < command line. Scalar and boolean flags follow last-wins, so the command line always overrides config.
Slice flags (--exclude-dir, --exclude-file, --exclude-ext, --include-ext, --not-match) union instead of overriding:

The three slice flags that ship with built-in defaults — --exclude-dir (.git, .hg, .svn), --exclude-file (the lockfile set) and --generated-markers — keep those defaults as a non-removable safety net: a config or CLI value is added to the defaults rather than replacing them, so putting vendor in .sccconfig never stops scc skipping .git.

Config can never write a file
A configuration file can change how scc counts and formats, including selecting a stdout format such as --format json, but it can never cause scc to write a file. The file-output flags — --output / -o, --report and --format-multi — are honoured only from the command line; the same flags supplied by config are ignored (output goes to stdout, the default). This is because a project .sccconfig is auto-discovered, so a cloned repository could otherwise silently overwrite one of your files. Only the command line can make scc write to disk.

Control flags
| Flag | Effect |
|------|--------|
| --no-config | Disable auto-discovery: skip the SCC_CONFIG_PATH global and the project .sccconfig. |
| --config <path> | Load this file as the global source. Always honoured, even with --no-config; overrides SCC_CONFIG_PATH. |
| --find-root-config | Discover the project .sccconfig by walking up to the repository root instead of using ./.sccconfig. No-op under --no-config. |

--config test.sccconfig --no-config loads exactly test.sccconfig and nothing else — a clean isolated-config mode. A --config or --no-config written inside a config file is inert (a config file cannot chain-load another config file).

The @file argument bundle

scc @flags.txt expands the contents of flags.txt as if its lines had been typed on the command line. It uses the same opts-list tokenizer as config files (comments, quotes, backslash-literal), but unlike config files it keeps positional paths and may write files — an @file is an explicit, user-supplied argument bundle equivalent to typing the flags, so it is trusted like the command line (including a --config inside it being honoured). @file expansion fires only when @file is the sole argument.

Note that because config discovery now runs on the post-@file arguments, scc @flags.txt in a directory containing ./.sccconfig loads both — the @file tokens sit above the config in precedence. To get the old "exactly these args, nothing else" behaviour, add --no-config.

Interesting Use Cases
Used inside Intel Nemu Hypervisor to track code changes between revisions <https://github.com/intel/nemu/blob/topic/virt-x86/tools/cloc-change.sh#L9>
Appears to also be used inside both <http://codescoop.com/> <https://pinpoint.com/> <https://github.com/chaoss/grimoirelab-graal>
It also is used to count code and guess language types in <https://searchcode.com/> which makes it one of the most frequently run code counters in the world.
You can also hook scc into your gitlab pipeline <https://gitlab.com/guided-explorations/ci-cd-plugin-extensions/ci-cd-plugin-extension-scc>
Used by the following products and services,
GitHub CodeQL - The CodeQL engine uses scc for line counting

JetBrains Qodana - The Qodana CLI leverages scc as a command-line helper for code analysis

Scaleway - Cloud provider using scc

Linux Foundation LFX Insights - COCOMO cost estimation
OpenEMS

Features
scc uses a small state machine in order to determine what state the code is when it reaches a newline \n. As such it is aware of and able to count

Single Line Comments
Multi Line Comments
Strings
Multi Line Strings
Blank lines
Because of this it is able to accurately determine if a comment is in a string or is actually a comment.
It also attempts to count the complexity of code. This is done by checking for branching operations in the code. For example, each of the following for if switch while else || && != == if encountered in Java would increment that files complexity by one.

Complexity Estimates
Let's take a minute to discuss the complexity estimate itself.
The complexity estimate is really just a number that is only comparable to files in the same language. It should not be used to compare languages directly without weighting them. The reason for this is that its calculated by looking for branch and loop statements in the code and incrementing a counter for that file.
Because some languages don't have loops and instead use recursion they can have a lower complexity count. Does this mean they are less complex? Probably not, but the tool cannot see this because it does not build an AST of the code as it only scans through it.
Generally though the complexity there is to help estimate between projects written in the same language, or for finding the most complex file in a project scc --by-file -s complexity which can be useful when you are estimating on how hard something is to maintain, or when looking for those files that should probably be refactored.

As for how it works.
It's my own definition, but tries to be an approximation of cyclomatic complexity <https://en.wikipedia.org/wiki/Cyclomatic_complexity> although done only on a file level.
The reason it's an approximation is that it's calculated almost for free from a CPU point of view (since its a cheap lookup when counting), whereas a real cyclomatic complexity count would need to parse the code. It gives a reasonable guess in practice though even if it fails to identify recursive methods. The goal was never for it to be exact.
In short when scc is looking through what it has identified as code if it notices what are usually branch conditions it will increment a counter.
The conditions it looks for are compiled into the code and you can get an idea for them by looking at the JSON inside the repository. See <https://github.com/boyter/scc/blob/master/languages.json#L3869> for an example of what it's looking at for a file that's Java.
The increment happens for each of the matching conditions and produces the number you see.
Unique Lines of Code (ULOC)
ULOC stands for Unique Lines of Code and represents the unique lines across languages, files and the project itself. This idea was taken from
<https://cmcenroe.me/2018/12/14/uloc.html> where the calculation is presented using standard Unix tools sort -u .h .c | wc -l. This metric is
there to assist with the estimation of complexity within the project. Quoting the source

> In my opinion, the number this produces should be a better estimate of the complexity of a project. Compared to SLOC, not only are blank lines discounted, but so are close-brace lines and other repetitive code such as common includes. On the other hand, ULOC counts comments, which require just as much maintenance as the code around them does, while avoiding inflating the result with license headers which appear in every file, for example.
You can obtain the ULOC by supplying the -u or --uloc argument to scc.

It has a corresponding metric DRYness % which is the percentage of ULOC to CLOC or DRYness = ULOC / SLOC. The
higher the number the more DRY (don't repeat yourself) the project can be considered. In general a higher value
here is a better as it indicates less duplicated code. The DRYness metric was taken from a comment by minimax <https://lobste.rs/s/has9r7/uloc_unique_lines_code>

To obtain the DRYness metric you can use the -a or --dryness argument to scc, which will implicitly set --uloc.

Note that there is a performance penalty when calculating the ULOC metrics which can double the runtime.
Running the uloc and DRYness calculations against C code a clone of redis produces an output as follows.

Further reading about the ULOC calculation can be found at <https://boyter.org/posts/sloc-cloc-code-new-metic-uloc/>

Interpreting Dryness,
75% (High Density): Very terse, expressive code. Every line counts. (Example: Clojure, Haskell)
60% - 70% (Standard): A healthy balance of logic and structural ceremony. (Example: Java, Python)
< 55% (High Boilerplate): High repetition. Likely due to mandatory error handling, auto-generated code, or verbose configuration. (Example: C#, CSS)
See <https://boyter.org/posts/boilerplate-tax-ranking-popular-languages-by-density/> for more details.
COCOMO
The COCOMO statistics displayed at the bottom of any command line run can be configured as needed.

To change the COCOMO parameters, you can either use one of the default COCOMO models.

You can also supply your own parameters if you are familiar with COCOMO as follows,

See below for details about how the model choices, and the parameters they use.

Organic – A software project is said to be an organic type if the team size required is adequately small, the
problem is well understood and has been solved in the past and also the team members have a nominal experience
regarding the problem.
scc --cocomo-project-type "organic,2.4,1.05,2.5,0.38"

Semi-detached – A software project is said to be a Semi-detached type if the vital characteristics such as team-size,
experience, knowledge of the various programming environment lie in between that of organic and Embedded.
The projects classified as Semi-Detached are comparatively less familiar and difficult to develop compared to
the organic ones and require more experience and better guidance and creativity. Eg: Compilers or
different Embedded Systems can be considered of Semi-Detached type.
scc --cocomo-project-type "semi-detached,3.0,1.12,2.5,0.35"

Embedded – A software project with requiring the highest level of complexity, creativity, and experience
requirement fall under this category. Such software requires a larger team size than the other two models
and also the developers need to be sufficiently experienced and creative to develop such complex models.
scc --cocomo-project-type "embedded,3.6,1.20,2.5,0.32"

LOCOMO
LOCOMO (LLM Output COst MOdel) estimates the cost to regenerate a codebase using a large language model. It is the LLM-era counterpart to COCOMO - a rough ballpark estimator, not a project planning tool.
Note: LOCOMO was developed as part of scc and is not an industry-standard model. Unlike COCOMO, which is based on decades of empirical research by Barry Boehm, LOCOMO is an experimental heuristic designed to give a useful order-of-magnitude estimate for LLM-assisted development costs. Treat its output as a conversation starter, not a definitive answer.

Important distinction: LOCOMO estimates the cost to regenerate known code - essentially "given this exact codebase, how much would it cost to have an LLM produce it?" This is fundamentally different from the cost to create something from scratch, which involves exploration, architectural decisions, dead ends, debugging, and iteration that can cost orders of magnitude more. COCOMO estimates the human creation cost; LOCOMO estimates the LLM regeneration cost. They answer different questions.
LOCOMO is opt-in. Enable it with --locomo or use --cost-comparison to display both COCOMO and LOCOMO side by side.

#### How it works

LOCOMO uses SLOC and complexity data that scc already computes. The model works per-file and aggregates:

Output tokens - each line of code maps to ~10 LLM output tokens (configurable).
Input tokens - estimated prompting cost, scaled by code complexity. More complex code (higher branch density) requires more detailed prompts. Scales to prevent runaway estimates.
Iteration factor - LLMs rarely produce correct code on the first try. A retry multiplier scales with complexity, also scales.
Dollar cost - input and output tokens multiplied by per-token pricing.
Generation time - total serial output tokens divided by tokens-per-second throughput.
Human review time - estimated per-line overhead for planning, review, testing, and integration.
Model presets
Presets are tier-based rather than tied to specific models, so they don't go stale as models are retired or renamed. Use --locomo-preset to select a tier:

| Preset | Represents | Input $/1M | Output $/1M | TPS |
|--------|-----------|-----------|-------------|-----|
| large | Frontier models (Opus, GPT-5.3, Gemini 3.1 Pro, etc.) | 10.00 | 30.00 | 30 |
| medium (default) | Balanced models (Sonnet, Gemini Flash, etc.) | 3.00 | 15.00 | 50 |
| small | Fast/cheap models (Haiku, GPT-4o-mini, etc.) | 0.50 | 2.00 | 100 |
| local | Self-hosted models (Llama, Mistral, Qwen etc.) | 0.00 | 0.00 | 15 |

For local, cost is $0 but generation time is still reported to capture the compute/time investment. Preset pricing reflects approximate tier rates as of early 2026 and can be overridden with explicit flags.

#### Overriding preset values

You can override individual preset values for pricing or throughput:

#### Human review time

The --locomo-review flag controls estimated human review minutes per line of code (default: 0.01, i.e. 0.6 seconds per line). This is intentionally optimistic and assumes light oversight.

For mission-critical, security-sensitive, or complex algorithmic code you should increase this:

#### Power-user configuration

The five internal model parameters can be overridden with a single comma-separated config string:

The defaults are "10,20,5,1.5,2". Here is what each parameter controls:

| Position | Name | Default | Description |
|----------|------|---------|-------------|
| 1 | tokensPerLine | 10 | Average LLM output tokens per line of code |
| 2 | inputPerLine | 20 | Base LLM input (prompt) tokens per output line |
| 3 | complexityWeight | 5 | How much complexity density scales input tokens: inputFactor = 1 + sqrt(density) * weight |
| 4 | iterations | 1.5 | Base iteration/retry cycles before complexity adjustment |
| 5 | iterationWeight | 2 | How much complexity density adds extra cycles: cycles = iterations + sqrt(density) * weight |

The iteration factor (cycles) scales both input and output tokens - it represents how many generation attempts the LLM needs. Simple code (~0.05 complexity density) produces ~1.9 cycles; complex code (~0.3 density) produces ~2.6 cycles. Use --locomo-cycles to override this with a fixed value.

For example, to model a cheaper/faster LLM that needs fewer tokens but more retries:

#### Comparing COCOMO and LOCOMO

Use --cost-comparison to show both estimates side by side. This enables COCOMO (if it was disabled) and LOCOMO together: