The previous post on the goat setup missed one piece: models like deepseek-v4-flash couldn't pick a thinking depth in /models. Digging in, it turned out the GOAT plan does support it — the problem was that the hand-written models in the custom provider were missing a reasoning capability declaration, so opencode's variant generation logic stopped them at the door. In the end I added reasoning:true to every model under goat and goat-zdr, and testing showed no side effects.

I bought CommandCode's goat plan and wanted to use it as my main plan in opencode. The whole integration takes just two steps: first /connect to save the API key, then declare the provider in opencode.json. The goat plan requires an x-cmd-zdr: 1 header on every request, and testing confirmed you can add that in the config too.

OpenCode Go's monthly quota is spread across several tables, and the official "5-hour quota" chart doesn't list all the models either. So I built a chart page that automatically scrapes the official pricing table, calculates the monthly available request count for each model using the same methodology as the official one, and plots it — hover for details.

In principle, autoregressive probabilistic prediction can never produce true creativity. I spent three months writing a novel with AI, took part in the entire journey of a book from signing to completion, and through countless rounds of practice mapped out the real boundaries of what AI can do. So where does humanity's true value lie? The answer isn't in what AI can do — it's in what AI can never do.

Use an LLM to build a persistent wiki instead of traditional RAG, so knowledge is compiled at ingestion time rather than re-derived at query time. Three-layer architecture: Raw Sources (immutable) → Wiki (LLM-maintained) → Schema (CLAUDE.md/AGENTS.md)

31B parameters, Apache 2.0 license, runs on a Mac Mini, AIME math jumps from 20% to 89% — Google's open-source models have finally turned things around this time. But tool calling is still a weak spot

Claude Code's memory system is not a single "memory" feature, but rather a **multi-layer, multi-scope, multi-lifecycle** memory architecture. It breaks down into:

Claude Code doesn't simply rely on the LLM's 256K/512K/1M context window to brute-force its way through. Instead, it has designed a **multi-layered, progressive** context management system. There are 6 layers of defense in total, triggered in order from lightest to heaviest, ensuring that AI response quality and speed are maintained at any interaction length.

`SummaryIndex` is a powerful tool in LlamaIndex for handling global questions. Its core mechanism is to **pass the complete document to the large model as context, leveraging the model's comprehension ability to generate a global summary or answer**. With sensible parameter configuration and a streamlined process, you can get high-quality global answers. In practice, it's a good idea to combine `VectorStoreIndex` and `SummaryIndex` and automatically pick the right query engine based on the type of question, so users get more comprehensive and accurate answers. This dual-engine architecture makes the most of both index types: it can handle specific local questions as well as questions that require reading the whole document to answer, providing solid support for building a high-quality Q&A system.

This afternoon, while reading through the MCP docs, I noticed that Claude's official documentation suggests copying the full text of documents longer than 50,000 characters straight into the conversation, which struck me as unreasonable (way too many input tokens). Curious whether today's large models can actually handle that, I gave it a try with Doubao — and the context overflowed. Trae's Builder also warned that it only supports prompts up to 6,000 characters. I normally ask questions with documents, so pasting content directly into the chat felt like "a battle fought with such deep pockets" — a novelty. In the end I had the AI tally up the context window sizes of mainstream large models.