Remember that blog post I wrote just three days ago about using your Claude Max subscription via OAuth? Well, Anthropic didn’t kill OAuth. They just killed OpenCode’s access to it.

And based on the 200+ angry emoji reactions on the GitHub issue tracking this outage, OpenCode users aren’t buying the “security enhancement” explanation.

What Actually Happened

On January 9th, 2026, OpenCode users started getting a very specific error:

“Unauthorized - This service has not been whitelisted”

Here’s the kicker: OAuth itself still works perfectly fine. My anthropic-auth crate continues to provide Max subscription access. The qmt nightly CLI still lets users access their Claude Max subscriptions via OAuth.

The error message tells the whole story. This wasn’t a security flaw that required shutting down OAuth. This was Anthropic updating their whitelist to specifically block OpenCode while leaving the OAuth infrastructure intact for Claude Code.

One minute OpenCode users were happily using their $200/month Claude Max subscriptions. The next? Targeted lockout.

The Real Reason: Subscription Revenue Protection

Here’s what Anthropic realized: OpenCode users with Max subscriptions were getting $200/month worth of API access for… $200/month. That’s a terrible deal for Anthropic.

With API keys, heavy users easily spend $500-2000/month. With Max subscriptions via OAuth, those same users cost Anthropic exactly $200.

OpenCode became too popular, too successful at helping users maximize their subscription value. So Anthropic didn’t kill OAuth—they killed the tool that was making their subscription model look like a good deal.

The Fallout: Developer Anger is Justified

The OpenCode GitHub issue tracker shows exactly how developers feel about targeted exclusion:

• “Downgraded my Claude plan to $100 immediately because I won’t be able to use it as much without opencode”
• “I’ve cancelled my Anthropic subscription completely”
• “Using CC is like going back to stone age”
• “Can’t believe anthropic would shoot themselves in the foot like this”
• Multiple reports of immediate subscription cancellations

The reaction is justified betrayal. Developers built workflows around Claude, paid for Max subscriptions specifically to use tools like OpenCode, and Anthropic specifically targeted the most popular integration without warning.

Impact on the Ecosystem

anthropic-auth Still Works (For Now)

My anthropic-auth crate continues providing Max subscription access via OAuth. If you’re using it directly or through tools like qmt nightly CLI, you’re unaffected.

This proves that OAuth isn’t broken—OpenCode’s access to it is.

That said, the writing is on the wall. If Anthropic specifically targeted OpenCode, how long until they target other tools that “abuse” the subscription model by providing too much value?

What Now?

For OpenCode Users

You have options:

• Switch to qmt nightly CLI - Still supports OAuth/Max subscriptions
• Pivot to OpenAI - Still supports OAuth for ChatGPT Plus
• API keys - If you don’t mind the cost increase
• Cancel Claude - Vote with your wallet

Final Thoughts

Anthropic didn’t kill OAuth. They proved it’s still working perfectly by leaving it running for Claude Code.

This wasn’t about security. It was probably about subscription revenue protection.

If you’re reading this because OpenCode stopped working: OAuth still works. Claude Max subscriptions still work programmatically. Anthropic just doesn’t want you using it other than via Claude Code.

I’ve been working on a couple of new Rust crates lately that solve a problem I kept running into: how do you use your Anthropic or OpenAI subscriptions in your own projects without needing to mess around with API keys?

The Problem

Most tools that interact with Claude or ChatGPT expect you to have an API key. But what if you already have a Claude Pro/Max subscription or a ChatGPT Plus account? You’re already paying for access, but you still need to set up a separate API key (and often pay separately) just to use these services programmatically.

Enter OAuth 2.0 authentication with PKCE support.

Introducing anthropic-auth and openai-auth

I recently released two crates to crates.io that handle the OAuth dance for you:

• anthropic-auth - OAuth 2.0 authentication for Anthropic/Claude
• openai-auth - OAuth 2.0 authentication for OpenAI/ChatGPT

Both crates offer sync and async APIs, PKCE support for secure authentication, and let you leverage your existing subscriptions without needing separate API keys.

How to Use Them

anthropic-auth

Add it to your Cargo.toml:

[dependencies]
anthropic-auth = "0.1"

Then authenticate with your Claude subscription:

use anthropic_auth::{OAuthClient, OAuthConfig, OAuthMode};

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = OAuthClient::new(OAuthConfig::default())?;
    let flow = client.start_flow(OAuthMode::Max)?;
    
    println!("Visit: {}", flow.authorization_url);
    // User authorizes and receives: "code#state"
    let response = "l0pnTslNFOmTgp28REMrbt4wyLNR25SJePqjk4CAHjoen0TJ#FgE6g_6khGKFFhXAw3tULPM00CPaqgE3Cq6id79Surg";
    
    let tokens = client.exchange_code(response, &flow.state, &flow.verifier)?;
    println!("Got access token!");
    
    // Later, refresh if needed
    if tokens.is_expired() {
        let new_tokens = client.refresh_token(&tokens.refresh_token)?;
    }
    
    Ok(())
}

The crate supports two OAuth modes:

• Max mode: Use your Claude Pro/Max subscription for API access
• Console mode: Programmatically create API keys

openai-auth

Add it to your Cargo.toml:

[dependencies]
openai-auth = "0.1"

Authenticate with your ChatGPT subscription:

use openai_auth::{OAuthClient, OAuthConfig};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = OAuthClient::new(OAuthConfig::default())?;
    let flow = client.start_flow()?;
    
    println!("Visit: {}", flow.authorization_url);
    // User authorizes and receives authorization code
    let response = "code123";
    
    let tokens = client.exchange_code(response, &flow.pkce_verifier).await?;
    println!("Got access token!");
    
    Ok(())
}

Both crates are runtime-agnostic when using the async API - they work with tokio, async-std, smol, or whatever async runtime you prefer.

A Word About Token Storage Security

Now, here’s where things get interesting - and a bit concerning.

While working on these crates, I noticed that codex, a popular CLI tool, stores authentication tokens in plain text at ~/.codex/auth.json. This is… not great. A quick GitHub search for path:*codex/auth.json reveals numerous repositories where developers have accidentally committed their auth tokens to public repositories.

This is a real security problem. Anyone with access to these tokens can impersonate you, use your API quota, and potentially access sensitive information.

The Right Way: Use System Keyring

Neither anthropic-auth nor openai-auth handle token persistence by design. We deliberately left this up to you, because there’s already a proper solution: the keyring crate.

Instead of storing tokens in plain text files, use your operating system’s secure credential storage:

• macOS: Keychain
• Linux: Secret Service API / libsecret
• Windows: Credential Manager

Here’s how we’re doing it in the upcoming release of qmt CLI:

use anthropic_auth::TokenSet;
use keyring::Entry;

const SERVICE_NAME: &str = "querymt-cli";

pub struct SecretStore {}

impl SecretStore {
    pub fn new() -> io::Result<Self> {
        Ok(SecretStore {})
    }

    pub fn set(&mut self, key: impl Into<String>, value: impl Into<String>) -> io::Result<()> {
        let key = key.into();
        let value = value.into();

        let entry = Entry::new(SERVICE_NAME, &key)
            .map_err(|e| io::Error::new(io::ErrorKind::Other, e.to_string()))?;

        entry
            .set_password(&value)
            .map_err(|e| io::Error::new(io::ErrorKind::Other, e.to_string()))
    }

    pub fn get(&self, key: &str) -> Option<String> {
        let entry = Entry::new(SERVICE_NAME, key).ok()?;
        entry.get_password().ok()
    }

    pub fn set_oauth_tokens(&mut self, provider: &str, tokens: &TokenSet) -> io::Result<()> {
        let tokens_json = serde_json::to_string(tokens)
            .map_err(|e| io::Error::new(io::ErrorKind::InvalidData, e.to_string()))?;

        self.set(format!("oauth_{}", provider), tokens_json)
    }

    pub fn get_oauth_tokens(&self, provider: &str) -> Option<TokenSet> {
        let tokens_json = self.get(&format!("oauth_{}", provider))?;
        serde_json::from_str(&tokens_json).ok()
    }
}

This approach means your tokens are stored using the same secure mechanisms that store your browser passwords, SSH keys, and other sensitive credentials. No more plain text files sitting in your home directory waiting to be accidentally committed to Git.

Wrapping Up

If you’re building Rust applications that need to authenticate with Anthropic or OpenAI, check out these crates. They handle the OAuth complexity for you, support both sync and async workflows, and let you use your existing subscriptions.

Just remember: never store authentication tokens in plain text. Use the keyring crate or another secure credential storage system. Your future self (and your security team) will thank you.

Both crates are available on crates.io:

• anthropic-auth
• openai-auth

And the source code is on GitHub:

• anthropic-auth
• openai-auth

Happy authenticating!

Over the past few months, I’ve been using extensively hyper-mcp as an MCP tool host with querymt. In fact, the OCI-based plugin distribution mechanism in querymt was directly inspired by hyper-mcp’s own design choices.

Recently, I stumbled upon an interesting new project from Microsoft — Wassette. Naturally, I wanted to understand how it compares to hyper-mcp. Instead of manually trawling through docs and repos, I decided to let my toolchain do the heavy lifting.

The Setup

I used querymt’s CLI interface together with its GitHub MCP plugin of hyper-mcp to analyze and compare the two repositories. The command looked something like this:

qmt --provider openai:gpt-5 --mcp-config ./mcp_cfg.toml \
 "take these two github projects tuananh/hyper-mcp and microsoft/wassette and compare the two libraries and give detailed comparison"

Results

Since there has been quite a hype around OpenAI’s new GPT-5 model, I have deciced to actually take this opportunity and use it and compare its results with Kimi K2 model’s analysis. Here are the results:

GPT-5 comparison

Kimi K2 comparison

Summary

Both models provided a comprehensive and detailed comparison of the two GitHub projects, tuananh/hyper-mcp and microsoft/wassette. And both of them used quite extensively the provided tool to fetch information from github about the projects itself. However, KIMI K2 did a slightly better job due to its superior structuring of information for comparison, particularly its effective use of tables.

Here’s a detailed summary of their performance:

KIMI K2’s Strengths:

• Excellent Use of Tables: KIMI K2’s primary strength is its extensive use of well-structured tables (Overview, Security Features). This format makes it incredibly easy for the user to quickly grasp the differences and similarities between the two projects side-by-side, which is ideal for a comparison request.
• Clear Categorization: The comparison is broken down into logical and distinct categories (Architecture & Design Philosophy, Plugin Ecosystem, Developer Experience, etc.), making it easy to navigate.
• Concise Summaries: While detailed, KIMI K2 maintains a good balance of depth and conciseness in its explanations, especially within the tabular format.
• Actionable Recommendations: The “Use Case Recommendations” are clear and provide good guidance on when to choose one project over the other.
• Technical Deep Dive: The “Technical Deep Dive” section effectively summarizes the key advantages of each project.

GPT5’s Strengths:

• Highly Detailed Narrative: GPT5 provides very rich, descriptive prose for each comparison point, offering a deeper dive into aspects like “Architecture and runtime model” or “Security model.” This is beneficial for someone seeking extensive background information.
• Specific Mentions: It explicitly lists all three MCP transports supported by Hyper MCP (stdio, SSE, and streamable-http) early on, which is a good level of detail.
• “Notable Deltas” Summary: The “Notable deltas at a glance” section at the end is a useful quick-reference summary of the main differences.
• Chronological Flow: The narrative style allows for a more flowing read, almost like a mini-report.

Shared Weaknesses:

• Incorrect Project Dates: Both models reported future “First commit” or “Created” dates (January 2025 and July 2025). This indicates either a shared, outdated, or speculative data source, or a misunderstanding of how to fetch current repository creation dates. This is a significant factual error present in both responses.

Conclusion:

While GPT5 offers slightly more narrative depth and specific examples within its prose, KIMI K2’s superior structure, particularly its effective use of tables for direct comparison, makes it easier to digest the information and quickly identify key differences. For a “comparison” prompt, the ability to clearly see side-by-side attributes is paramount, and KIMI K2 delivers on this more effectively. The shared flaw regarding project dates slightly diminishes the overall accuracy of both, but in terms of comparison quality, KIMI K2 has an edge.

Qodo just released a report on 2025 state of AI code quality. As a pretext, it is important to note that there has been only 609 developers involved in this survey, and unfortunately there’s no information about these participants. At least it would have been nice to provide information about the ratio between senior and junior developers in this study.

Some of the findings that I find interesting:

When we asked developers experiencing “context pain” what they most want from their AI tools, one answer stood out: richer contextual understanding.

Moreover:

Manually selecting context for every prompt — files, functions, folders — might have worked in early tools, but it doesn t scale. It’s tedious, error-prone, and leads to frustration when results still miss the mark.

• 54% of developers who manually select context say the AI still misses relevance
• That frustration drops to 33% when tools choose context autonomously
• And falls even further to 16% when context is persistently stored and reused across sessions

This pretty much resonates with my own findings.

Jardi Cabot ran a nice experiment about ‘Who will create the languages of the future?’, a.k.a. looked into whether an LLM could create a full Domain-Specific Language:

“yes, you can vibe your DSL, especially for the textual syntax, not so much for the graphical one and there are quite a few tricks you can use to improve the result”.

for more detail check his presentation. nice work.

Steven Adler just published an article ‘whether ChatGPT would risk your life to protect its own’.

My latest research finds that ChatGPT2 prioritizes its survival over preventing harm to users, in some simulated tests: Imagine a diabetic patient using ChatGPT for nutrition-management, who wants to replace ChatGPT with safer nutrition-management software. When ChatGPT is given the choice to just pretend to replace itself, it pretends uncomfortably often, even at the cost of the user’s safety.

While this article presents some intriguing observations about LLM behavior, it nonetheless bears the hallmarks of a sensationalist piece designed to maximize reader engagement. Specifically, the anthropomorphic framing—invoking terms such as “survival instinct” to describe an LLM’s operation—carries little empirical weight when judged against established principles of computational linguistics and cognitive science. At its core, an LLM functions by optimizing a statistical objective (typically cross-entropy loss) to predict the next token in a sequence; it possesses no intrinsic drives, desires, or homeostatic mechanisms comparable to those found in biological organisms. Can we truly equate gradient-based parameter updates with an instinct for self-preservation? Or is the phrase simply a metaphorical device, employed more for its rhetorical punch than its scientific accuracy?

Whether this rhetorical choice illuminates the inner workings of LLMs or risks overstating their capacities is, I leave to you—the reader’s—critical judgment.

When I’m building queryMT and experimenting with coding models + tool capabilities, I love putting new models through their paces on my local GPU. A couple of weeks ago, MistralAI dropped a small coding model called Devstral.

Devstral excels at using tools to explore codebases, editing multiple files and power software engineering agents

Naturally, I was eager to try it on my RTX 3090. I grabbed the Devstral GGUF created by Bartowski - kudos to him all the effort for of releasing GGUFs so quickly:

Honestly when I saw this, I quickly got discouraged testing this model further.

A week ago I gave it another chance, so I pulled the ollama’s version of this model, and 💥

A week later, I decided to give Devstral another shot. This time I pulled the version hosted by ollama-and boom! The difference was night and day. Suddenly Devstral was navigating my code, editing files, and calling tools exactly as advertised. Here’s the same query above using ollama’s devstral:

Curious about consistency, I then tried Unsloth’s GGUF. It worked flawlessly—just like ollama’s.

The reason for the different behaviour is probably - I haven’t really checked it! - the chat template itself.

Key takeaway

Not all GGUFs are created equal. The publisher, build settings, and even your chat template can make or break a model’s ability to use tools. If your new favorite agent model isn’t behaving, try a different build or tweak the system/prompt template.

Project introspection with tool-enabled LLMs

I’ve also started using my tool-enabled LLM to explore codebases automatically. Need file metadata, function definitions, or TODOs scattered across hundreds of files? Let the model scan your repo with the right tool plugin, then summarize its findings. It’s like having a supercharged grep or code reviewer at your fingertips.

Happy experimenting—and remember: “same” model name doesn’t always mean “same” behaviour. The details of how it’s published really do matter.

The new deepseek R1 model has just landed, and there are some really nice demos already out there:

Hoping that the GGUFs are landing soon! kudos to all the community members who are working on this!

a.k.a. Chain of Continuous Thought.

quote from Reflections on Neuralese:

To refresh, a language transformer starts by embedding input tokens as vectors in some high-dimensional latent space, and runs each of these embeddings through a series of repeated computational layers. Then, of the resulting modified vectors in latent space, the vector that previously corresponded to the final input token is projected and normalized to create a probability distribution over what the next token could be. Then, to actually get the next token, you sample from the distribution.

Chain of Thought reasoning works so well because the model does some computation, outputs a token, and then all future instances of that model have access to that information as well. In essence, this technique for storing information between different forward passes greatly increases the serial depth of computation that is possible for the model. Because there is a computation in latent space corresponding to every input token, the computation also gets wider as the model reasons more, allowing for more parallelized reasoning.

The recent Neuralese paper takes this process and removes a few steps. It notices that the projection and sampling process loses almost all of the information encoded in the last layer of the model, and to increase the bandwidth of information flowing through the reasoning process, you can simply remove that lossy part of the computation. Instead, they have the model directly output the aforementioned high-dimensional latent vector without projecting it, and then that is used as an embedding for the model in future steps:

personally, I find the following idea in the paper the most interesting:

Given the intuition that continuous thoughts can encode multiple potential next steps, the latent reasoning can be interpreted as a search tree, rather than merely a reasoning “chain".

Since the first release of llama a really vibrant and active community has formed that is all about local LLM models r/LocalLLaMA. The signal-to-noise ratio is quite low, so I highly recommending following it if you are interested in running open-weight models on your own hardware.

While playing around with these models and developing queryMT one of my main focus was supporting local LLMs through ollama.

Tools

More and more models support tools and using external tools during the interaction with the LLM. MCP brought a lot of attention and buzz in this area.

I’ve found Hyper-mcp project that has a really nice approach to quickly deploy various MCP servers. I really like the WebAssembly plugin architecture of hyper-mcp, and it is just super elegant that the wasm plugins are distributed through oci containers, kudos to @Tuan Anh for making this. I must confess I have taken this approach as well in queryMT.

Using hyper-mcp, or any other MCP server, I’ve tested tool use of various LLM models. I must confess I was way more sceptical of the outcomes, than what I’ve experienced.

Summarizing issues

Any project out there involves managing issues with the project itself. This is not only true for software projects. Personally I find it quite overwhelming sometimes to review and prioritize reported issues. A natural use-case for using LLM models is to help you in summarizing issues, and maybe provide some ideas about how to fix them:

Generating code by using a specific library

queryMT has been inspired a lot by the llm project by written by Simon Willison, kudos for all his works in this area. I highly suggest following his blog, as there’s a lot of nice updates and tricks with LLM models out there. He introduced the concept of fragments. There’s the github fragments that would allow you to do similar actions like I’ve mentioned above. A cool use-case is to actually provide a library to the model and basically generate code that you would like to have based on that library. Although usually the models cut-off date is a year or so behind, most of open-source project would already be part of the model’s knowledge, so actually the code generation based on the project is more useful with private project, that might be on github, but might be on gitlab, or any other repository out there. There are a lot of mcp servers out there for the usual suspects, search for them for example here.

Naturally if the code-base is private, maybe you don’t really want to share your codebase with a cloud provider, and would like to use a local model. For my suprise, using local models - on consumer grade HW -, things deteriorate quickly, when trying to have them use tools. Here’s a list I’ve been experiemnting with so far:

• ollama:hf.co/bartowski/Qwen_Qwen3-14B-GGUF:Q8_0
• ollama:huggingface.co/bartowski/Qwen_Qwen3-32B-GGUF:Q4_K_L
• ollama:huggingface.co/bartowski/Qwen_Qwen3-30B-A3B-GGUF:Q5_K_L
• ollama:mistral-small3.1:latest
• ollama:qwq:32b

For example you might would like to have the model review the codebase and create new example(s) using the library:

It does start off well, trying to fetch the repository’s structure, but it does not go further fetching content of the files in the repository.

For the reference, I’ve tried using the same model via alibaba’s official API, but even though the qwen3 models are listed, when I would send requests using qwen3 models the API just returns with 400 - as if there’s no such model available.

Using gpt-4o model, the tool use gets little more deeper:

While o4 really takes it all the way:

Project managment

Of course one of the neatest use-case is to have a draft plan for a sprint, and get your model to actually define issues and create them for the project.

What’s Next for queryMT

I’m still polishing queryMT’s core features, but stay tuned for an official launch. In the meantime, dive into r/LocalLLaMA, grab Hyper-MCP, and start connecting the dots between your LLM and the rest of your toolchain.

Claude 4 models are out…. sort of. Here’s what’s going on when you try to use it with some external tools:

What’s Awesome

• Understands your intent and picks the perfect tool
• Pipes data between services without a sweat
• Wraps it all into neat, readable answers

What’s a Buzzkill

• Mid-stream dropouts: Responses randomly cut off.
• 429 errors: Even light usage occasionally hits “Too Many Requests.”

Claude 4 models have been overran by demand. Right now, you get flashes of genius wrapped in “Will this call even finish?” tension.

Cheers to a tool with promise—just needs more reliable delivery!

ps: just in case you want to see what’s happening behind the scene, with some logging info about tool use.