100xprompt understands your code the way your editor does. As it reads and edits your project, it taps into language servers for real, compiler-grade intelligence: the exact errors and warnings your code would produce, where a symbol is defined, everywhere it’s used, its type and documentation on hover, and a searchable map of the symbols in your codebase. Instead of guessing, the agent checks - so you get fewer broken edits and precise, grounded navigation. This page covers the edit → diagnostics loop, the capabilities it unlocks, the supported languages, and how to configure servers.

Get IDE-grade signal

Language servers give 100xprompt the same signal a human engineer gets from a good IDE. Two things change once that signal is available.

Fewer broken edits

After every edit, 100xprompt sees the real diagnostics for the file it just changed - type errors, undefined names, bad imports. It catches mistakes immediately and fixes them before handing the change back to you.

Precise navigation

Instead of grepping and guessing, the agent jumps straight to a definition, lists every reference, reads a symbol’s type and docs, and searches symbols by name - so it edits the right code, not something that merely looks similar.

Catch broken edits in the loop

The tight loop between editing and diagnostics is the biggest win. When 100xprompt writes or edits a file, it re-checks that file through the language server and surfaces any new errors or warnings right away. If the edit introduced a problem, the agent sees it and corrects course - no waiting for you to run a build.
Diagnostics are reported with severity, line, and column - the same error / warning / info / hint levels your editor shows - so 100xprompt prioritizes real errors over style hints.

What language intelligence gives the agent

Beyond diagnostics, 100xprompt asks the language server precise questions about your code as it works.
CapabilityWhat it does
DiagnosticsLive errors and warnings surfaced for a file right after it’s edited.
Go to definitionJumps to where a symbol is declared.
Find referencesLists every place a symbol is used across the project.
HoverReads a symbol’s type signature and documentation.
Go to implementationFinds concrete implementations of an interface or abstract type.
Document symbolsOutlines the classes, functions, and types in a single file.
Workspace symbolsSearches symbols by name across the whole project.
Call hierarchyTraces incoming and outgoing calls for a function.
These run automatically when they help the task - you don’t invoke them by hand. They let 100xprompt refactor across files with confidence: it finds every caller before changing a signature, then confirms the change is clean afterward.

Supported languages

Language support works automatically. When 100xprompt touches a file in a supported language and the required toolchain is present, it connects to the matching language server in the background - no setup, no configuration. For some languages it fetches the server for you on first use; for others it relies on the toolchain you already have installed (for example, a project’s own dependencies, or a compiler like Go, Rust, or Swift).
Out of the box, 100xprompt has language servers for TypeScript and JavaScript (including Deno projects), Vue, Svelte, Astro, Python, Go, Rust, Ruby, C / C++, C#, F#, Java, Kotlin, Swift (and Objective-C), Elixir, Zig, PHP, Dart, Lua, OCaml, Haskell, Gleam, Clojure, Nix, Bash / shell scripts, YAML, Prisma, Terraform, Dockerfile, LaTeX, and Typst. JavaScript and TypeScript projects also get lint-level diagnostics from ESLint, Oxlint, and Biome when those are set up in the project.
100xprompt detects the right project root automatically - respecting workspaces, monorepos, and per-language project files - so diagnostics and navigation reflect your real project setup, not an isolated file.

Configure language servers

Language intelligence is on by default and needs no configuration. When you do want control - add a server for a language that isn’t built in, override how a built-in one launches, or turn one off - configure it under the lsp key in your 100xprompt.json.

Add a custom language server

Give the server a name and a command to launch it (as an array), plus the file extensions it handles. You can optionally pass environment variables and initialization options.
100xprompt.json
{
  "$schema": "https://100xprompt.com/config.json",
  "lsp": {
    "my-language": {
      "command": ["my-language-server", "--stdio"],
      "extensions": [".mylang"],
      "env": {
        "MY_LANG_MODE": "strict"
      },
      "initialization": {
        "someServerOption": true
      }
    }
  }
}
For a custom server, the extensions array is required - that’s how 100xprompt knows which files the server should handle.

Override a built-in server

Use a built-in server’s name as the key to change how it starts - for example, to point at a specific binary or pass extra flags. The keys accept the same command, extensions, env, and initialization fields.
100xprompt.json
{
  "lsp": {
    "typescript": {
      "command": ["typescript-language-server", "--stdio"]
    }
  }
}

Disable a single language server

Set disabled on the server you want to turn off. The rest keep working.
100xprompt.json
{
  "lsp": {
    "eslint": { "disabled": true }
  }
}

Disable all language intelligence

Set lsp to false to switch off every language server. The agent still reads and edits code normally - it just won’t get live diagnostics or language-aware navigation.
100xprompt.json
{
  "lsp": false
}
FieldTypePurpose
lspfalse or objectfalse disables all language intelligence; an object configures servers by name.
commandarray of stringsThe command and arguments used to launch the server.
extensionsarray of stringsFile extensions the server handles. Required for custom servers.
disabledbooleanTurns a single server off.
envobjectEnvironment variables passed to the server process.
initializationobjectServer-specific initialization options.
Usually not. For many languages 100xprompt fetches the language server automatically the first time it’s needed. Others rely on the toolchain already on your machine - for example, your project’s own dependencies, or a compiler such as Go, Rust, or Swift. If a required toolchain isn’t present, 100xprompt simply skips that server and continues; your edits still work, just without live diagnostics for that language.

Tips

Keep your project files tidy

Project markers (lockfiles, go.mod, Cargo.toml, pyproject.toml, and the like) help 100xprompt pick the correct root, which makes diagnostics and navigation more accurate.

Lean on it for refactors

Because it can find every reference before changing a symbol, 100xprompt is at its best on multi-file refactors - ask for the rename or signature change and let it verify the result.

Writing & Editing Code

See how edits are drafted, reviewed, and verified - the loop diagnostics plug into.

Codebase Understanding

See how 100xprompt maps your project before it changes anything.

Settings

Read the full 100xprompt.json reference, including the lsp key.