Which coding clients can authenticate to Sume: key or OAuth?

Five coding clients (JetBrains, Jan, Kimi Code CLI, Tabnine, Augment) and the credential route each vendor page documents for Sume's endpoint.

5 min readSume
All posts

Of five clients checked on 2026-10-02, Jan and Kimi Code CLI document an OAuth sign-in that fits Sume, Kimi and Tabnine document header-based API keys, and the JetBrains AI Assistant and Augment extension pages document a URL but not a credential. Sume needs one or the other.

Sume's hosted endpoint accepts an OAuth access token or an API key (bearer or x-api-key). A client that can do neither cannot connect, however well it handles the URL.

What does Sume require from a client?

From the OAuth and API keys page: for OAuth the client follows the protected-resource metadata, sends the user to the consent page on the MCP host, and exchanges the code with PKCE. For an API key, it sends Authorization: Bearer <key> or x-api-key. OAuth defaults to mcp:read; Write is an opt-in at consent. A key sees the full tool set.

What does each vendor page document?

Only what each page says, nothing inferred:

Credential routes documented by each vendor, read 2026-10-02
ClientOAuth sign-inStatic headerFits Sume as documented
JanYes: metadata discovery, dynamic registration, PKCENot documentedOAuth route
Kimi Code CLIYes: --auth oauth, kimi mcp authYes: --header "KEY: value"Either route
TabnineDescribed for SSE servers onlyYes: requestInit.headersKey route
Augment extensionNot documentedNot documentedUnconfirmed
Augment CLINot documentedYes: headers in add-jsonKey route
JetBrains AI AssistantNot documentedNot documentedUnconfirmed

How do you test an unconfirmed client?

Add the entry with only the URL, Apply, and look at the connection state. A client that supports OAuth will usually start a sign-in on its own; one that does not will show an authorization error and no tools. If it shows no sign-in, try the header route if one exists, and if neither works, run the same job from a client in the table that does document a route.

A successful connection is proven by mcp_health (check the auth source) and tools_list, as the Sume quickstart suggests.

Which route should you prefer?

OAuth for interactive use: it is the preferred path in the Sume docs, defaults to read-only, and keeps keys out of config files. API keys for automation, in a file that is not committed, rotated if exposed. Do not mint an API key just to work around a client that lacks OAuth for a person to use; the docs call that out as a workaround to avoid for hosted OAuth clients.

What does this table not tell you?

It reflects the pages as read on 2026-10-02, not the software itself. A client can support more than its documentation says, and documentation can lag a release. Treat a not documented cell as a prompt to test, not as a no.

It also says nothing about tool counts, approval prompts or timeouts, which differ by client and decide how safe a paid call is. Check the client's tool timeout against Sume's 55 second wait cap, and its approval mode against how much you trust the session, before the first real generation.

Sources

Related posts

More in Comparisons

All Comparisons posts

Written by Sume