Development Tools on KnightLi Blog

Obsidian vs Joplin: A Markdown Notes App Comparison Guide

Sat, 30 May 2026 14:43:56 +0800

Obsidian and Joplin are both Markdown note-taking tools, but they suit different kinds of users.

In short, Obsidian is better for deep knowledge management, backlink-based Zettelkasten workflows, and users who want heavy customization. Joplin is better for practical users who care about data privacy, need cross-platform sync, prefer traditional folder-style organization, and rely on web clipping.

If you want to build a “second brain”, write long-term research notes, tinker with plugins, and use knowledge graphs, start with Obsidian. If you want a safer and more open alternative to Evernote or Youdao Cloud Notes, start with Joplin.

Core Differences

Dimension	Obsidian	Joplin
Open-source status	Closed source, free for personal use, paid for commercial use	Fully open source, AGPL-3.0 license
Data storage	Local `.md` plain text files	Local database management, with note content written in Markdown
Data control	Files live directly in local folders, making migration and backup straightforward	Managed through the app or export features, but supports encryption and sync
Official sync	Obsidian Sync, paid	Joplin Cloud, paid
Free sync	Requires third-party options such as iCloud, Git, Jianguoyun, Syncthing, etc.	Built-in support for sync targets such as OneDrive, Dropbox, WebDAV, and file system
Core strengths	Backlinks, knowledge graph, plugin ecosystem, strong customization	Web clipping, end-to-end encryption, cross-platform sync, open source
Organization style	Relationship network, backlinks, tags, folders	Notebooks, sub-notebooks, notes, tags
Onboarding experience	Powerful, but easy to become more complex over time	Closer to traditional note apps and easier to start with

Data Management and Privacy

Obsidian’s key idea is “files as data”. Your notes are ordinary .md files stored directly in a local folder. Even if you stop using Obsidian in the future, you can still open those files with any text editor.

This approach is intuitive, open, easy to back up, and suitable for Git-based management. The downside is that sync, attachment management, and multi-device consistency require more planning from the user.

Joplin also uses Markdown syntax, but notes are managed by the app’s local database. Its advantage is a more complete application layer: notes, attachments, tags, and sync status are all handled by the app. Joplin also natively supports end-to-end encryption (E2EE), so when you sync through a third-party cloud drive, the cloud provider has a harder time reading note content directly.

If you care more about “my notes are local files”, Obsidian feels more natural. If you care more about “the app helps me manage sync, encryption, and attachments”, Joplin is easier.

Sync Options and Cost

Obsidian’s official sync service is Obsidian Sync. It works well, but it is paid. If you want free sync between phone, tablet, and computer, you need to configure a third-party option such as iCloud, Git, Syncthing, Jianguoyun, or another WebDAV workflow. This is fine for people familiar with file sync, but it adds friction for beginners.

Joplin’s sync leans more toward built-in capability. It supports Joplin Cloud, and it also supports OneDrive, Dropbox, WebDAV, file system sync, and other sync targets. Once an account or endpoint is configured, notes can sync across devices.

Need	Better Fit
You are willing to pay for official sync and want a low-friction experience	Either Obsidian Sync or Joplin Cloud works
You want free sync through third-party cloud storage	Joplin is more direct
You are familiar with Git / Syncthing / iCloud and do not mind tinkering	Obsidian also works very well
You want end-to-end encryption during sync	Joplin has it more built in

Plugin Ecosystem and Customization

Obsidian’s plugin ecosystem is one of its strongest parts. Through plugins, it can become a task board, flashcard tool, calendar, mind map, personal database, or even something close to a local knowledge system.

Backlinks, reverse links, local graphs, and plugins like Dataview can gradually turn scattered notes into a knowledge network. For writing books, research, knowledge cards, and project material accumulation, this capability is very attractive.

Joplin also supports plugins, themes, and some linking features, but its ecosystem and room for tinkering are not as rich as Obsidian’s. The upside is restraint: it is less likely to make users spend a lot of time changing themes, testing plugins, and redesigning the interface.

If your goal is “deeply customize a knowledge management system”, Obsidian is stronger. If your goal is “stable note-taking, sync, and search”, Joplin is already enough.

Web Clipping

Web clipping is one of Joplin’s strengths. It provides an official Web Clipper that can save web pages, simplified article content, page screenshots, or links from the browser. For people who collect offline material, save technical articles, and organize web content, this is very practical.

Obsidian’s native web clipping capability is relatively weak and usually depends on third-party browser extensions or other workflows. There are many available options, but the experience and stability depend on the plugin and the structure of each web page. Clipped content may also require manual formatting afterward.

Scenario	Better Fit
Frequently saving web articles	Joplin
Building an offline reference library	Joplin
Occasionally saving web links	Both are fine
Saving content and then heavily rewriting or linking it	Obsidian

Organization Style Differences

Obsidian is more like a knowledge network built on top of local folders. You can organize with folders, but also with tags, backlinks, reverse links, and graphs. It is well suited to nonlinear notes and knowledge bases with complex relationships between topics.

Joplin is closer to traditional note-taking software. It uses a hierarchy of notebooks, sub-notebooks, and notes, while also supporting tags. For people used to tools like Evernote, Youdao Cloud Notes, or OneNote, Joplin’s organization style feels more familiar.

Preference	Recommendation
You like folders + backlinks + graphs	Obsidian
You like notebooks + sub-notebooks + tags	Joplin
Academic research, book writing, or Zettelkasten	Obsidian
Reference collection, project notes, and web archiving	Joplin

Which One Should You Choose?

Choose Obsidian if:

You are doing long-term research, writing a book, organizing course material, or building a personal knowledge base.
You care about backlinks, reverse links, and knowledge graphs.
You want to deeply customize the interface, hotkeys, plugins, and workflow.
You are willing to spend time tuning sync, plugins, and file structure.
You want notes to exist directly as local Markdown files.

Choose Joplin if:

You want an open-source, cross-platform, sync-capable traditional notes app.
You care about end-to-end encryption and data privacy.
You often use web clipping to save articles.
You do not want to pay for basic sync or spend time building a complex sync workflow.
You are more comfortable with notebooks, sub-notebooks, and tags.

Short Conclusion

Obsidian and Joplin are not a question of which one is absolutely better. They have different design goals.

Obsidian is more like a highly customizable Markdown knowledge management platform. It suits people who enjoy building systems, working with backlinks, and playing with plugins. Its ceiling is high, but it can also make people enjoy building the system more than writing notes.

Joplin is more like a traditional notes app that is open source, syncable, and encryptable. It suits people who want stable note-taking, web clipping, multi-device sync, and long-term preservation of material. It does not have Obsidian’s backlink ecosystem, but it is closer to a tool that lets you install it and start taking notes seriously.

In one sentence: choose Obsidian if you want to build a second brain; choose Joplin if you want an open-source Evernote.

Joplin: An Offline-First Open-Source Notes App with Sync and Encryption

Sat, 30 May 2026 14:39:48 +0800

Joplin is an open-source notes and to-do app for Windows, macOS, Linux, Android, and iOS. It is not just a lightweight memo app, but a knowledge management tool designed for storing many notes over the long term, syncing them across devices, and keeping as much control as possible in the user’s hands.

Joplin notes use Markdown and support notebooks, tags, full-text search, attachments, to-dos, plugins, themes, and a browser Web Clipper. For people who want to move away from Evernote, or manage personal information in a more open format, it is a very common choice.

What Problem Does Joplin Solve?

Many note apps are convenient, but their data can easily become locked into a specific account, cloud service, or private format. Joplin takes a more open approach: it keeps complete data locally, stores note content in Markdown, and then syncs between devices through a sync target chosen by the user.

It is suitable for several needs:

You want to keep notes as Markdown over the long term.
You want to sync notes between a computer and a phone.
You want to import old Evernote notes and attachments.
You want to use end-to-end encrypted sync.
You want to extend the notes app with plugins and themes.
You want to quickly clip web content into your own note library.

Core Features at a Glance

Feature	Description
Open source	Public repository, long-term maintenance, licensed under the AGPL-3.0 license
Cross-platform	Supports Windows, macOS, Linux, Android, and iOS
Markdown	Note bodies use Markdown, which helps with reading, migration, and long-term preservation
Offline-first	Data is always stored locally, so notes can be viewed and edited without a network connection
Sync	Supports multiple sync targets, including Joplin Cloud, Nextcloud, Dropbox, OneDrive, and others
End-to-end encryption	E2EE can be enabled during sync to reduce the risk of exposing content in cloud storage
Import	Supports importing from Evernote and from normal Markdown files
Extensions	Supports plugins, themes, and Web Clipper

What Does Offline-First Mean?

The official Joplin README emphasizes that it is “offline first”. This means notes are not stored only in the cloud; they are saved on the local computer or phone. Even without a network connection, you can still open, search, and edit existing notes.

This design matters a lot for a notes app. When the network is unstable, a sync service is temporarily unavailable, or an account service has problems, the complete data still exists locally. Sync keeps multiple devices consistent, but it does not make the entire experience depend on the cloud.

Markdown and Import Capability

Joplin uses Markdown for notes, which makes it easier to migrate and back up than a fully proprietary format. Users can import normal Markdown files directly, and they can also import notes from Evernote.

When importing from Evernote, Joplin tries to convert formatted content and preserve resources such as images and attachments. It also keeps metadata such as creation time, update time, and location when possible. For people with years of Evernote data, this matters much more than simply copying text.

Still, no cross-app migration should be trusted as a one-click perfect process. Complex layouts, tables, attachments, internal links, and tag structures should be tested with a small sample first before migrating the full library.

Sync and Encryption

Joplin supports several sync methods. Common choices include:

Sync Target	Suitable Scenario
Joplin Cloud	You want the simplest official service
Nextcloud	You already have a self-hosted cloud or team collaboration environment
Dropbox	You are already used to Dropbox
OneDrive	You use the Microsoft ecosystem
File system / WebDAV, etc.	You want more control over the sync location

Sync can be used together with end-to-end encryption. After it is enabled, note content is encrypted before being synced to the cloud, so the cloud service mostly stores encrypted data. This reduces the risk that a third-party cloud drive or sync service can expose note content.

Encryption also adds management cost. Users need to keep passwords and recovery information properly; otherwise, old notes may become impossible to decrypt after changing devices or reinstalling the app.

Web Clipper and Plugins

Joplin also provides a browser Web Clipper for saving web pages and screenshots from browsers such as Chrome and Firefox. For people who collect reference material, clip web pages, or build research notes, this is a practical entry point.

Plugins and themes make Joplin closer to an extensible platform than a fixed-function notes app. Users can expand editing, display, search, import, and export capabilities according to their own workflows.

Differences from Obsidian

Joplin and Obsidian are often compared by Markdown users, but they emphasize different things.

Dimension	Joplin	Obsidian
Main positioning	Open-source notes and to-do app with built-in sync options and encryption	Local Markdown knowledge base focused on backlinks, plugins, and graphs
Data organization	The app manages notebooks, tags, attachments, and database indexes	Works directly around folders and Markdown files
Sync	Built-in sync targets and E2EE	Official sync is paid; third-party sync can also be configured manually
Best suited for	People who want ready-to-use cross-device sync with privacy features	People who want a highly customized local file-based knowledge workflow

If you want an “open-source Evernote + Markdown + encrypted sync” experience, Joplin is closer to that need. If you want to build a highly customized knowledge system around local Markdown files, Obsidian may feel smoother.

Who Is Joplin For?

Joplin is suitable for several types of users:

People who want to migrate away from Evernote.
Users who want to keep notes in Markdown.
People who need sync across Windows, macOS, Linux, Android, and iOS.
People who care about privacy and want end-to-end encryption.
People who want note software that is open source, self-hostable, and easy to migrate away from over the long term.
People who need web clipping and attachment management.

It is not necessarily ideal for people who only want the simplest sticky-note tool. Joplin is fairly complete, and setting up sync, encryption, plugins, and imports still requires some time to understand.

Usage Suggestions

If you plan to try Joplin, start in this order:

Create a test notebook on the desktop app first.
Import a small Markdown or Evernote sample.
Check whether images, attachments, tags, creation time, and formatting are normal.
Then set up a sync target, such as Joplin Cloud, Nextcloud, Dropbox, or OneDrive.
If you want to enable end-to-end encryption, first confirm that every device can sync and decrypt correctly.
Finally, migrate the full note library.

This is safer than importing years of notes in one go, and it makes it easier to discover formatting or sync problems before the formal migration.

My Take

Joplin’s strength is that it combines several important directions: Markdown, open source, cross-platform support, offline-first storage, sync, and end-to-end encryption. It is not just a Markdown editor, but more like a personal note system designed for long-term use.

If you want note data to stay as open as possible, but do not want to assemble sync, encryption, and mobile apps entirely by yourself, Joplin is worth trying. It is especially suitable for users migrating from Evernote, caring about privacy, using multiple devices, and hoping their data can still be moved elsewhere in the future.

Project link: laurent22/joplin
Official documentation: Joplin documentation

Jimmy: Convert Exports from Evernote, Notion, Google Keep, and More into Markdown

Sat, 30 May 2026 11:55:56 +0800

Jimmy is a note conversion tool whose goal is to convert content from different note apps or document formats into Markdown. It is useful for people who want to move notes out of closed apps, import them into Obsidian or Joplin, or simply keep long-term archives as plain text.

The project documentation is very direct: export or back up the original note app’s data, run jimmy to convert it, then import the result into Joplin or Obsidian, or open it directly in a text editor such as VSCode.

What Jimmy Solves

Many note apps have their own export formats. When switching apps, the hardest part is often not the text itself, but images, attachments, tags, internal links, and structured metadata such as front matter.

Jimmy tries to turn those exports into a more universal Markdown directory:

Convert note bodies to Markdown.
Preserve images, resources, and attachments as much as possible.
Preserve tags, external links, and internal note links where possible.
Output Markdown + front matter.
Make the result importable into Joplin, Obsidian, and similar tools, or readable directly in a text editor.

The point of this kind of tool is to reduce migration cost. Once notes become Markdown, they are no longer tightly bound to one app. Backup, search, version control, and LLM processing all become much easier.

Many Supported Note Apps

Jimmy supports a wide range of sources, including Anki, Anytype, Bear, CherryTree, ColorNote, Day One, Diaro, Drafts, Dynalist, Evernote, Google Docs, Google Keep, Joplin, Notion, Obsidian, OneNote, QOwnNotes, RedNotebook, Reflect, Roam Research, Signal, Simplenote, Standard Notes, Synology Note Station, Telegram, Tiddlywiki, Turtl, UpNote, Wordpress, Zim, Zoho Notebook, and more.

Not every source has the same fidelity. In a real migration, you should still test with a small batch first and check images, attachments, tags, internal links, and date fields carefully.

It Can Also Convert Regular Documents

Besides exports from note apps, Jimmy can also handle common document formats. The docs mention converting a single file or recursively converting an entire folder, which makes it useful for turning messy document directories into Markdown.

Common supported formats include:

Type	Examples
Office documents	DOCX, ODT, RTF
Markup languages	Asciidoc, DocBook, Markdown, MediaWiki, reStructuredText
Web and ebooks	HTML, MHTML, EPUB
Data and structured files	CSV, OPML, Jupyter Notebook
Other	PDF, EML, Fountain, txt2tags

If you only want to batch-convert DOCX, PDF, or HTML into Markdown, Jimmy can also work as an offline batch-processing tool.

Two Ways to Use It

Jimmy provides both CLI and TUI interfaces.

Interface	Best For	Notes
CLI	Batch processing, scripts, full functionality	Suitable for converting folders, writing migration scripts, and specifying source formats
TUI	Interactive conversion	Suitable for manual operation; currently a beta subset of the full functionality

The official README gives these Linux examples:

# Convert with the interactive TUI
jimmy-linux tui

# Convert a single file supported by pandoc
jimmy-linux cli libre_office_document.odt

# Convert an entire folder
jimmy-linux cli path/to/folder

# Convert a Google Keep export
jimmy-linux cli takeout-20240401T160516Z-001.zip --format google_keep

These commands show that Jimmy is not only for one note app. It puts “note export packages” and “regular document folders” into the same conversion workflow.

Main Characteristics

Feature	Description
Offline execution	Conversion does not depend on cloud services, which is useful for private notes
Open source	The repository uses the GPL-3.0 license
Cross-platform	Official downloads are available for Linux, Windows, and macOS
Standalone binary	Users do not need to install Docker, Python, or Node.js
No AI used	Conversion does not call AI, making results more controllable and reducing privacy concerns
Markdown + front matter	Easy to import into note apps and later manage with Git

“Offline” and “no AI” are especially fitting for note migration. Notes often contain private information, work materials, and old attachments. Keeping conversion local makes the risk boundary clearer.

Who Should Use It

Jimmy is useful for:

Users migrating from Evernote, Notion, OneNote, Google Keep, and similar tools to Markdown.
People importing notes into Obsidian, Joplin, or another plain-text workflow.
People who want to preserve long-term materials in a format that will be easier to read in the future.
People preparing notes or documents as text that LLMs can process.
People who need to recursively convert folders of DOCX, PDF, HTML, ODT, and similar files.

It may not be for users who expect “one-click perfect migration”. Export formats vary greatly between note apps, and complex pages, databases, embeds, and internal links may still need manual review.

Pre-Migration Checklist

Before doing a real migration, it is better to follow this order:

Export a small sample from the original note app.
Convert the sample with Jimmy instead of converting everything immediately.
Check Markdown body text, images, attachments, tags, creation time, and internal links.
Confirm that the target app, such as Obsidian or Joplin, recognizes the directory structure and front matter correctly.
Convert the full export package.
Keep both the original export and converted result until you have verified everything.

This is a bit slower, but it avoids discovering missing attachments, broken links, or wrong tag structure only after the migration is done.

My Take

Jimmy is useful because it turns note migration from “relying on one app’s importer” into “convert to universal Markdown first”. It supports many sources, and its output is general enough to help free a personal knowledge base from closed formats.

If you only export one or two notes occasionally, you may not need it. But if you have years of notes, attachments, and document folders and want to move to Obsidian, Joplin, or a Git-managed Markdown workflow, Jimmy is worth trying. It is best used as a migration middle layer: first turn data into readable, backup-friendly, batch-processable text, then decide which note system should own it.

Project link: marph91/jimmy
Documentation: Jimmy - Note Conversion Tool

Google Pay and Wallet Launch Developer MCP Server: Bringing Payment Integration Into AI Assistants

Fri, 29 May 2026 15:24:18 +0800

Google Developers has released the Google Pay and Wallet Developer MCP Server. Built for developers integrating the Google Pay API and Google Wallet API, it connects official documentation, account status, integration checks, and some business metrics to MCP-compatible AI development tools.

This kind of update may not look as flashy as a model launch, but it is very practical for developers. Payment and wallet integrations are often less about whether someone can write the code and more about dense documentation, many configuration items, review requirements, and scattered error feedback. The value of an MCP Server is that it lets an AI assistant help developers troubleshoot from a position much closer to the real context.

What Problem It Solves

When developers integrate Google Pay or Google Wallet, they usually have to switch back and forth across several places:

Checking official documentation and sample code
Confirming account and merchant configuration
Inspecting request parameters and returned errors
Verifying whether the integration meets requirements
Observing call performance and key metrics

If these resources are treated only as web documentation, an AI assistant can mostly explain concepts or generate examples. After connecting to an MCP Server, the assistant can access more specific information through tools and provide suggestions that are closer to the current project state.

Why MCP Fits Here

MCP provides standardized tool interfaces for AI applications. For developer products such as Google Pay and Wallet, it is especially well suited to tasks that combine documentation, status, and validation.

For example, developers can ask an MCP-capable AI tool to help answer:

Which configuration items are missing from the current integration
Why a particular Google Pay request failed
Which fields in a Wallet pass definition may not meet the requirements
How a code sample should be adapted to the current business need
Which items still need to be checked before the integration goes live

These questions are risky if answered only from a large model’s memory. When the answer can combine official tools with current account information, it becomes much more actionable.

What It Means for AI Coding Workflows

This release also points to a trend: AI coding assistants are moving from “reading code” to “reading product systems.”

In the past, when developers asked AI to help integrate payment capabilities, they usually had to paste in documentation snippets, error logs, and code. AI could explain them, but it did not necessarily know the real state of the current integration. MCP Server pushes that capability one step forward, giving AI assistants a chance to work directly around the product integration environment.

This is especially valuable in several scenarios:

A new project integrates Google Pay or Wallet for the first time.
An old project migrates to a new API or configuration approach.
The team performs integration checks before launch.
The team needs to quickly locate issues involving error codes, review problems, or configuration mismatches.

For teams, the benefit is not just reading a few fewer pages of documentation. It is reducing the friction of “the documentation was understood correctly, but the live configuration does not match.”

It Will Not Replace Developer Judgment

Payment and wallet integrations involve security, compliance, and user experience requirements. MCP Server can help AI assistants find information faster, check status, and generate suggestions, but developers still need to confirm the code, security strategy, merchant configuration, and launch process.

This is especially true for payment flows. A seemingly reasonable AI suggestion should not be pushed directly to production. A more reliable approach is to treat MCP tools as inspectors and navigators: they can shorten the time needed to locate a problem, but they cannot replace review, testing, or business responsibility.

My Take

The significance of the Google Pay and Wallet Developer MCP Server is not that there is “one more MCP example.” It is that MCP has been placed inside a real, complex, highly constrained developer scenario.

If MCP only connects to documentation, its value is limited. If it can connect to account status, integration validation, metrics, and product backends, AI assistants can take on more practical development work. Google’s release shows exactly that direction.

Similar capabilities are likely to appear in more cloud services, advertising platforms, payment systems, and enterprise SaaS products in the future. Developers need to adapt not just to “AI can write code,” but to “AI can participate in the entire integration process through standardized tool interfaces.”

Original link: Supercharge your integration workflow with the Google Pay & Wallet Developer MCP Server

Remotion: Generate Videos Programmatically with React

Wed, 27 May 2026 14:39:22 +0800

remotion-dev/remotion is a framework for creating videos programmatically with React. It pulls video production out of traditional timeline tools and turns it into a frontend engineering problem that can be controlled with components, state, data, API, CSS, Canvas, SVG, WebGL, and algorithms.

Project address: remotion-dev/remotion

This kind of tool fits today’s AI coding workflows very well: if an agent can generate web pages, charts, and data views, it can also keep going and generate video scripts, animation components, and renderable short films.

What Problem Does Remotion Solve

Traditional video tools are good at manual editing, but not at scale, parameterization, or automation.

For example, these tasks:

Generate a personalized annual recap video for each user
Automatically generate product demo videos from a database
Combine charts, code snippets, and explanatory subtitles into technical short videos
Batch-generate marketing assets, social media short videos, or course clips
Render videos on demand through CI/CD or backend services

With traditional editing software, these tasks are hard to fully automate. Remotion’s approach is to write video as a React application: every frame is the result of components and data at a specific point in time.

Why React

The reason given in the Remotion README is straightforward: React can reuse Web technologies and component-based development.

It lets you use:

CSS for layout and animation
SVG for vector graphics
Canvas and WebGL for complex drawing
JavaScript / TypeScript for variables, functions, API calls, math, and algorithms
React components for reuse, composition, and fast iteration

This means frontend developers do not need to learn an entirely unfamiliar video DSL from scratch. Many existing UI pieces, charts, design systems, and data logic can be moved into video generation scenarios.

Quick Start

If Node.js is already installed, the entry command given in the README is:

`1`	`npx create-video@latest`

After creating a project, you typically write React components to describe the scene, then let Remotion render the video frame by frame.

For more complete documentation, see:

Docs: remotion.dev/docs
API Reference: remotion.dev/api

What Scenarios Is It Good For

Remotion is best suited to scenarios where “video content is driven by data or code.”

Personalized Videos

Examples include annual recaps, user achievements, order summaries, and learning reports. Each user’s data is different, but the visual structure is the same. Using React components plus data-driven rendering feels more natural than manual editing.

Technical Demo Videos

If a video contains code, charts, product interfaces, step animations, and explanatory text, Remotion is well suited to organizing these elements into templates that can be rendered repeatedly.

Data Videos and Chart Animations

Data visualization is already a frontend strength. Remotion lets charts appear not only on web pages, but also enter videos along a timeline.

AI-Generated Video Workflows

An AI agent can first generate scripts and asset structures, then generate Remotion components, and finally render the video. This is more controllable than asking a model to directly generate the final video, because the intermediate artifact is code that can be inspected, edited, versioned, and reused.

Why It Matters for AI Coding Tools

Remotion is especially interesting for AI coding tools such as Codex, Claude Code, Cursor, and Gemini CLI.

The reason is that video generation is broken down into development tasks:

Generate React components.
Adjust styles and layout.
Connect data.
Preview the scene.
Modify based on feedback.
Render the output.

This workflow is a very good fit for agents: every step has files, code, a preview, and clear feedback. Compared with “directly generating a video file,” code-based video is easier to review and iterate on.

Combined with browser sidebars, screenshot inspection, automated rendering, and comment feedback, Remotion can become the video artifact layer inside an AI workflow.

Check the License Before Use

The Remotion README specifically notes that Remotion has a special license, and that certain company usage scenarios require a company license.

So do not treat it as just another small MIT utility. License requirements may differ for personal projects, open-source projects, commercial projects, and internal enterprise tools. Before using it in company production, you should first read its LICENSE page and official licensing notes.

This is important, especially when connecting Remotion to automated content generation, marketing asset generation, or internal enterprise video pipelines.

My Take

Remotion’s value is not just “making videos with React”; it is turning video into something programmable, reusable, and automatable.

For ordinary frontend teams, it is suitable for data-driven video templates. For AI tools, it is more like a stable output target: the model does not need to generate a black-box video in one shot, but can instead generate readable, editable, renderable React code.

If your content needs batch generation, personalization, updates based on data, or repeated visual adjustments by an agent, Remotion is worth putting into the toolbox. It is not a replacement for traditional editing software, but a way to connect video production to a software engineering workflow.

CLIProxyAPI Management Center: A Visual Admin Console for CLIProxyAPI

Sun, 24 May 2026 10:05:15 +0800

Cli-Proxy-API-Management-Center can be understood as the cockpit for CLIProxyAPI.

In the previous article, CLIProxyAPI was the service that proxies Gemini CLI, Codex, Claude Code, OpenRouter, and other capabilities into unified APIs. This Management Center solves a different problem:

Once the proxy service is running, should configuration, accounts, OAuth, logs, quotas, and credentials all be managed by manually editing files and scrolling through terminals?

It provides a web management interface so you can manage CLIProxyAPI configuration and runtime state from a browser.

What It Is

According to the project description, Cli-Proxy-API-Management-Center is an independent management frontend for CLIProxyAPI. Its core features include:

Visual editing for CLIProxyAPI configuration.
Uploading and managing authentication files such as auth.json.
Viewing request logs and model response logs.
Managing OAuth authentication flows.
Checking Gemini CLI account quotas.
Providing daily maintenance entry points for accounts, configuration, logs, and related tasks.

The official repository also notes that newer versions of CLIProxyAPI already include this management interface, accessible directly through /management.html. The standalone repository remains useful for people who need separate deployment or secondary development.

That point matters. Most ordinary users may not need to deploy this repository separately. First check whether your CLIProxyAPI version already ships with the management page.

It Manages the Entry Point, Not the Model Call Itself

The hard part of CLIProxyAPI is not only forwarding a request to a model.

The real trouble is in things like:

How to put multiple Gemini, OpenAI, Claude, and Codex accounts into a pool.
Which account has expired, and which account is close to its quota limit.
How to import, refresh, and troubleshoot OAuth login states.
How to edit configuration files without missing commas or fields.
Which provider, model, and account a request actually used.
Whether a failed request came from an upstream issue, a protocol issue, or local configuration.

This is where Management Center is useful: it turns daily maintenance of proxy infrastructure into visual operations.

If you only run one account locally and call the API occasionally, it may not be essential. But once you start using multiple accounts, multiple models, and multiple client integrations, a backend UI becomes noticeably easier to live with.

Typical Use Cases

First: managing account pools.

CLIProxyAPI supports multi-account rotation and load balancing, but the more accounts you have, the less suitable manual configuration-file editing becomes. The management center helps you view account state, import credentials, and troubleshoot abnormal accounts.

Second: troubleshooting failed requests.

When a client reports an error, you need to know whether the request reached the proxy, which provider it used, and what error came back. A log UI is much more comfortable than searching through terminal output.

Third: handling OAuth.

Tools such as Codex, Claude Code, and Gemini CLI often involve OAuth login state. Management Center provides OAuth-related operation entry points, reducing repeated command-line work.

Fourth: internal team usage.

If CLIProxyAPI becomes a shared team gateway, administrators need an interface for quickly checking configuration and state. Otherwise, every change requires logging into a server and editing files, which is inefficient and error-prone.

How It Relates to CLIProxyAPI

You can think of the two pieces as separate layers:

Client / IDE / Script
        |
        v
CLIProxyAPI: protocol proxy, account pool, model routing
        |
        v
Gemini CLI / Codex / Claude Code / OpenRouter / upstream models

Management Center is not in the core inference request path. It is more like an operations panel:

Browser
  |
  v
Management Center: edit config, view logs, manage accounts, check quotas
  |
  v
CLIProxyAPI admin APIs / config / logs / credentials

So do not treat it as another model proxy. It is a tool for managing CLIProxyAPI, not a replacement for CLIProxyAPI.

Why the Standalone Repository Still Matters

Since CLIProxyAPI already includes /management.html, why pay attention to the standalone repository?

There are three main reasons.

First, the standalone repository makes the management center’s boundaries easier to inspect. You can see what belongs to the frontend, and what must be provided by CLIProxyAPI backend APIs.

Second, if you want secondary development, such as changing the UI, adding authentication, or integrating your own monitoring system, the standalone repository is a better entry point.

Third, if your deployment environment is unusual, such as separate frontend and backend hosting, a dedicated management domain, or static assets served through an internal gateway, the standalone version is more flexible.

For ordinary individual users, the built-in CLIProxyAPI version is usually enough. For teams or deep customization, the standalone repository is more meaningful.

What to Watch During Deployment

The admin console touches sensitive things: accounts, OAuth, API keys, logs, request contents, and upstream quotas.

So the first rule is: do not expose the management page directly to the public internet.

Safer options include:

Allow only local access, such as binding to 127.0.0.1.
If remote access is necessary, put it behind a VPN, Tailscale, an internal jump host, or an authenticated reverse proxy.
Add authentication to admin endpoints. Do not rely on “nobody knows the URL”.
Avoid exposing full keys, cookies, OAuth tokens, and raw user requests in logs.
In team environments, separate people who can call the API from people who can change configuration.

Many proxy-tool incidents do not come from model call failures. They come from unprotected admin endpoints, logs, and credential files.

What to Use It With

If you only deploy CLIProxyAPI, a management center already solves basic maintenance needs.

If you care more about statistics and observability, you can also combine it with other tools in the CLIProxyAPI ecosystem:

CPA Usage Keeper: focused on usage syncing and SQLite storage.
CLIProxyAPI Usage Dashboard: focused on local-first usage, quota, and chart views.
CPA-Manager: a heavier management center for request monitoring, cost estimation, account inspection, and abnormal account cleanup suggestions.

A simple way to understand the division:

Management Center handles configuration and daily maintenance.
Usage Dashboard handles usage and quota visibility.
CPA-Manager handles heavier operations and inspections.

Which one to use depends on your deployment size. A personal local setup does not need the whole suite.

Usage Suggestions

If you are just starting with CLIProxyAPI, try this order:

First get CLIProxyAPI itself running and confirm the API responds normally.
Open the built-in /management.html and check whether configuration and logs can be read.
Import one account or one provider, and confirm the management UI reflects the state change.
If you need public access, add authentication and network isolation before exposing the entry point.
After the number of accounts and requests grows, add usage statistics and more complete management tools.

Do not connect every account, every provider, and every management component at once from the beginning. Proxy and account-pool projects are much easier to verify in small steps.

Conclusion

Cli-Proxy-API-Management-Center has a clear role: it is not a model, not a chat client, and not a new API gateway. It is the visual management layer for CLIProxyAPI.

When CLIProxyAPI is just a small local tool, you can ignore it. When CLIProxyAPI starts carrying multiple accounts, multiple models, and multiple client integrations, it becomes a very useful console.

The real thing to watch is the security boundary. The admin backend can modify configuration, view logs, and touch credentials. If exposed incorrectly, its risk is higher than an ordinary API calling endpoint. Keep it in a trusted network, protect it with authentication, and then enjoy the convenience of visual management.

References:

CLIProxyAPI: Wrapping Codex, Claude Code, and Gemini CLI into a Unified API

Sun, 24 May 2026 10:03:33 +0800

CLIProxyAPI is a very practical, community-engineering kind of project. It is not another large model, and it is not merely an API forwarder. Instead, it repackages a set of AI tools that are originally interactive, CLI-oriented, or OAuth-login-oriented into a unified API service.

It supports Gemini CLI, OpenAI Codex, Claude Code, Amp CLI, AI Studio Build, and upstream OpenAI-compatible services. In plain terms, it tries to answer this question:

I have CLI tools, subscription accounts, and OAuth login sessions. Can I connect these capabilities to my own client, scripts, IDE, or internal services just like calling a normal API?

CLIProxyAPI’s answer is yes: put a proxy layer in the middle and translate CLI capabilities from different sources into OpenAI-, Gemini-, Claude-, and Codex-compatible interfaces.

The Real Pain Point It Solves

Many AI coding tools are powerful, but their default usage patterns are not automation-friendly.

For example:

Gemini CLI can log in with an account, but your program may prefer calling an HTTP API.
Claude Code is excellent for interactive coding, but integrating it into other clients can run into protocol mismatches.
Codex CLI supports OAuth login and Responses-style capabilities, but not every upper-layer tool knows how to talk to it.
A team may have multiple accounts and need rotation, load balancing, unhealthy account removal, and quota visibility.
You may want some tools to see only an OpenAI-style interface, while the backend is actually Gemini, Claude, or Codex.

CLIProxyAPI is positioned as the protocol adaptation layer between these tools and your clients.

It hides the complex side behind the scenes: OAuth, CLI login, multiple accounts, different protocols, and different providers. On the front side, it exposes familiar interfaces such as OpenAI Chat Completions, OpenAI Responses, Gemini, Claude Messages, and Codex-related endpoints.

Capability Overview

According to the official README and documentation, CLIProxyAPI currently focuses on:

Providing OpenAI-, Gemini-, Claude-, and Codex-compatible API endpoints for CLI models.
Connecting OpenAI Codex and Claude Code through OAuth login.
Supporting streaming and non-streaming responses, plus WebSocket in some scenarios.
Supporting function calling, tool calling, and multimodal input.
Supporting multi-account rotation and load balancing for Gemini, OpenAI, and Claude.
Supporting Gemini AI Studio API keys.
Supporting account pools for AI Studio Build, Gemini CLI, Claude Code, and OpenAI Codex.
Connecting OpenAI-compatible upstreams through configuration, such as OpenRouter.
Providing a Go SDK so the proxy capability can be embedded into your own services.

The most valuable part of this kind of project is not that it supports a few more model names. It is that it packages account login, protocol translation, and request routing into one operational layer.

Who It Is For

CLIProxyAPI is better suited to several groups of users.

The first group is heavy AI coding users. You already use Codex, Claude Code, and Gemini CLI, but you want to connect them to Cursor, Cline, RooCode, Amp, internal scripts, or custom workflows.

The second group is people with multiple account pools. For example, you may have several Gemini, OpenAI, or Claude login sessions and do not want to switch manually. You want automatic rotation, balanced usage, and quick troubleshooting when an account becomes abnormal.

The third group is people building internal team gateways. The team may not want every client to separately adapt to Gemini, Claude, and Codex. Instead, it wants one middle layer that exposes a unified API.

The fourth group is people who like working with protocols. You may care how Responses, Chat Completions, Claude Messages, and Gemini v1beta interfaces can be converted between one another, or you may want to switch backends from the same client.

If you only ask AI a few questions occasionally, or only use the official apps for chat, the deployment and maintenance cost of CLIProxyAPI may feel heavy.

How It Differs from a Regular API Proxy

A typical API proxy looks like this:

`1`	`Client -> Proxy API -> Upstream model API`

CLIProxyAPI is closer to this:

`1`	`Client -> CLIProxyAPI -> CLI / OAuth session / account pool -> model service`

The difference is that it handles more than API key forwarding. It also deals with CLI tools, OAuth accounts, protocol surfaces, and model aliases.

Tools such as Codex and Claude Code are not traditional “give me one API key and I can call it stably” services. CLIProxyAPI wraps their login sessions and calling logic so external clients can access them as if they were normal APIs.

That is what makes it attractive, and also what makes it complex.

Common Misunderstandings

First, do not assume that a unified /v1/... path eliminates all protocol differences.

The CLIProxyAPI documentation specifically notes that when you need the request and response shape of a certain backend type, you should prefer provider-specific paths. For example, use /api/provider/{provider}/v1/messages for messages-style requests, /api/provider/{provider}/v1beta/models/... for Gemini model paths, and /api/provider/{provider}/v1/chat/completions for chat-completions-style requests.

A unified entry point is convenient, but the semantics of different protocols do not disappear. Tool calling, streaming responses, multimodal input, and system message handling may all differ by backend.

Second, a model name does not uniquely identify a backend.

If multiple backends expose the same client-visible model name, the path alone may not lock the request to the backend that actually performs inference. To strictly pin a backend, use unique aliases, prefixes, or avoid exposing the same model name from multiple backends.

Third, multi-account rotation is not unlimited quota.

Rotation only spreads usage more evenly across the account pool. It cannot bypass the real limits of upstream services. Abnormal accounts, exhausted quota, risk controls, and expired OAuth sessions still need monitoring.

Fourth, it is not a maintenance-free magic box.

Once you put it into your daily workflow, you need to care about configuration, logs, upstream account status, version upgrades, client compatibility, and security boundaries.

Management and Monitoring

The official README notes that since v6.10.0, CLIProxyAPI and CPAMC no longer include built-in data statistics. If you need usage statistics, you can use separate projects:

CPA Usage Keeper: syncs CLIProxyAPI data into SQLite and provides aggregation APIs and a dashboard.
CLIProxyAPI Usage Dashboard: a local-first usage and quota dashboard that can show accounts, models, time windows, and remaining Codex quota.
CPA-Manager: a fuller management center for request monitoring, cost estimation, account pool inspection, abnormal account location, and cleanup suggestions.

This suggests that CLIProxyAPI’s core is closer to a proxy and protocol layer, not an all-in-one commercial admin backend. If a team uses it, logs, monitoring, and account pool management should be considered from the beginning.

A Reasonable Way to Try It

If you want to test it, a safer order is:

Start it with the official Quick Start documentation.
Connect only one provider first, such as Gemini CLI or Codex, and confirm basic requests work.
Then test higher-risk capabilities such as streaming responses, tool calling, and multimodal input.
Confirm which endpoint the client actually uses, and avoid mixing protocol paths.
Finally add multi-account rotation, management panels, and usage statistics.

Do not connect Gemini, Codex, Claude, OpenRouter, multiple accounts, and all clients at once from the start. When something breaks, it becomes hard to tell whether the issue is authentication, protocol conversion, model naming, or the upstream account.

Think Through the Security Boundary

CLIProxyAPI can touch account login sessions, API keys, OAuth-related credentials, and request contents. If it only runs on your own machine, the risk is relatively manageable. If it is exposed to the public internet or a team intranet, authentication, access control, log redaction, and network isolation become mandatory.

Management endpoints especially should be limited to localhost or a trusted internal network. Do not expose management interfaces directly just to save a few minutes.

Conclusion

CLIProxyAPI’s value is that it gathers AI capabilities scattered across multiple CLIs, accounts, and protocols into one programmable API layer.

It fits heavy AI coding users, multi-account users, and internal team gateway scenarios. It is less suitable for lightweight users who want something completely plug-and-play with no maintenance.

If you are already experimenting with Codex, Claude Code, and Gemini CLI, and want to connect them to your own client or automation workflow, CLIProxyAPI is worth a serious look. Treat it as infrastructure, not as a disposable small utility.

References:

Two Ways to Use DeepSeek Models with Codex: Local Gateway and OpenRouter BYOK

Sun, 24 May 2026 09:52:55 +0800

If you want Codex to use DeepSeek, the first instinct is usually to edit ~/.codex/config.toml:

1
2

model = "deepseek-chat"
base_url = "https://api.deepseek.com"

That idea can work in some older versions or in regular OpenAI SDK scenarios. But with the current Codex CLI, it can easily run into a lower-level mismatch: custom model providers in Codex use the OpenAI Responses protocol, while DeepSeek’s official API is mainly exposed through an OpenAI-compatible Chat Completions interface.

My local version is currently codex-cli 0.111.0. codex --help shows support for configuration entry points such as --config, --model, and --profile. The official OpenAI Codex configuration reference is also explicit: model_providers.<id>.wire_api currently supports only responses, and defaults to responses when omitted.

DeepSeek’s official docs, meanwhile, show the call path as https://api.deepseek.com/chat/completions, with examples such as client.chat.completions.create(...). So the issue is not that DeepSeek cannot be called through OpenAI-style tooling. The issue is that the request semantics Codex sends are not exactly the same as what DeepSeek’s native API understands.

That is why changing base_url directly to https://api.deepseek.com may produce symptoms such as:

The request path does not match, resulting in a 404 or an unexpected response format.
Multi-turn conversations, tool calls, or patch generation fail during parsing.
tool_calls order, message structure, or streaming event format does not line up.
The model seems able to answer a plain prompt, but starts failing once Codex does real work.

The steadier approach is to put a translation layer between Codex and DeepSeek. There are two common routes.

Method 1: Bridge DeepSeek Through a Local Gateway

A local gateway should do more than simple forwarding. Its job is to convert Responses-style requests from Codex into Chat Completions-style requests that DeepSeek can handle, then convert DeepSeek’s result back into a format Codex can consume.

If you use a local gateway such as ccx, the configuration idea looks roughly like this:

[profiles.deepseek-ccx]
model = "deepseek-v4-flash"
model_provider = "ccx-bridge"

[model_providers.ccx-bridge]
name = "Local CCX Gateway"
base_url = "http://localhost:3000/v1"
env_key = "DEEPSEEK_API_KEY"

Then set the DeepSeek key in your terminal and start Codex with that profile:

1
2

export DEEPSEEK_API_KEY="your-deepseek-key"
codex --profile deepseek-ccx

In PowerShell:

1
2

$env:DEEPSEEK_API_KEY="your-deepseek-key"
codex --profile deepseek-ccx

There are two details to watch.

First, base_url should point to the gateway endpoint exposed to Codex, not the official DeepSeek address. The gateway calls DeepSeek behind the scenes.

Second, the correct value for env_key depends on how the gateway handles authentication. Some gateways read the official DeepSeek key directly. Others ask you to provide a local proxy key, while storing the DeepSeek key in the gateway backend. In that case, env_key should be changed to whatever environment variable the gateway expects.

This route is local and controllable, and it is easier to reason about latency and cost. The tradeoff is that you must confirm the gateway really supports the current Responses semantics used by Codex, rather than only acting as a basic Chat Completions proxy.

Method 2: Use OpenRouter BYOK as an Online Bridge

If you do not want to run a local gateway, OpenRouter BYOK is another option. BYOK means binding your own upstream provider key to OpenRouter, which then handles routing and forwarding.

The most common mistake here is the environment variable. Codex is calling OpenRouter, so env_key should usually be OPENROUTER_API_KEY, not DEEPSEEK_API_KEY. The DeepSeek key should be added in OpenRouter’s BYOK or provider key settings.

Example configuration:

[profiles.deepseek-openrouter]
model = "deepseek/deepseek-chat"
model_provider = "openrouter"

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"

Start it like this:

1
2

export OPENROUTER_API_KEY="your-openrouter-key"
codex --profile deepseek-openrouter

PowerShell:

1
2

$env:OPENROUTER_API_KEY="your-openrouter-key"
codex --profile deepseek-openrouter

Then add your DeepSeek provider key in the OpenRouter dashboard. OpenRouter’s BYOK documentation says provider keys are stored encrypted and used for routing to the corresponding provider.

This route saves you from maintaining a local gateway and feels more like using a regular third-party API proxy. The downside is that an online service sits in the middle, so troubleshooting may require checking Codex, OpenRouter, and DeepSeek error messages together.

Should You Keep Using the deepseek-chat Model Name?

In DeepSeek’s documentation as of May 2026, the recommended model names include deepseek-v4-flash and deepseek-v4-pro, with a note that compatibility aliases such as deepseek-chat and deepseek-reasoner will be deprecated after 2026-07-24.

For new configurations, it is better to test:

`1`	`model = "deepseek-v4-flash"`

If you are using OpenRouter, follow OpenRouter’s model naming format, for example:

`1`	`model = "deepseek/deepseek-chat"`

The actual available names depend on your gateway or OpenRouter’s model page. When the model name is wrong, errors usually look like model not found, 404, or the provider failing to find the matching endpoint.

Why Directly Setting DeepSeek’s Official base_url Is Not Recommended

You can certainly try this as an experiment:

[profiles.deepseek-direct]
model = "deepseek-v4-flash"
model_provider = "deepseek"

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com"
env_key = "DEEPSEEK_API_KEY"

But this is more of a debugging experiment than a stable setup. Codex talks to custom providers through the Responses protocol, while DeepSeek’s official examples use /chat/completions. If DeepSeek or Codex adds a full compatibility layer later, direct connection may become simple. Until then, a bridge layer is more reliable.

What If Codex Still Uses OpenAI After Editing the Config?

First, confirm the config file location. The global config should be:

`1`	`~/.codex/config.toml`

The project-level .codex/config.toml is not the right place for machine-level provider settings such as model_provider and model_providers. The official OpenAI docs also note that project-level configuration does not override local provider and authentication fields.

If Codex still asks you to log in through the web, or appears to use the default OpenAI model, log out first:

`1`	`codex logout`

Some older tutorials write this as /logout inside the interactive UI. With the current CLI, running codex logout directly in the terminal is the more reliable option.

You can also run a quick check with a temporary profile:

`1`	`codex --profile deepseek-ccx`

Or:

`1`	`codex -c model_provider=ccx-bridge -c model=deepseek-v4-flash`

If that works, the config itself is readable. If it does not, check the profile name, TOML syntax, and whether the environment variable only exists in the current shell session.

Troubleshooting Checklist

401: The key is wrong, or env_key points to the wrong environment variable.
404: base_url or the model name is wrong, or a Responses request is being sent to an endpoint that only supports Chat Completions.
tool_calls, patch, or streaming parse errors: the protocol bridge is likely incomplete.
Still prompted to log in to OpenAI: run codex logout, then confirm you are using the correct profile.
PowerShell environment variable disappears in a new window: $env:... only applies to the current session. Use user environment variables if you need it to persist.
OpenRouter BYOK is not using your own DeepSeek key: check whether the provider key is bound in OpenRouter, whether the current OpenRouter API key is allowed to use it, and whether fallback is enabled.

Conclusion

Using DeepSeek with Codex is not impossible through config.toml. The catch is that changing only base_url is usually not enough.

The two steadier routes today are:

Use a local gateway as a protocol bridge: Codex talks to the local gateway, and the gateway talks to DeepSeek.
Use OpenRouter BYOK as an online proxy: Codex talks to OpenRouter, while the DeepSeek key is bound in the OpenRouter dashboard.

If you only want a quick test, OpenRouter is easier. If you want tighter control over keys, cost, and logs, a local gateway is better for long-term tinkering.

References:

What is CodeGraph? A local code map for Claude Code, Codex, and Cursor

Sat, 23 May 2026 21:09:46 +0800

CodeGraph is a local code knowledge graph designed for AI coding tools. It indexes a project ahead of time and organizes symbol relationships, call graphs, code structure, route relationships, and related information into a queryable graph. That lets Claude Code, Codex CLI, Cursor, OpenCode, Hermes Agent, and similar tools avoid relying on grep, glob, Read, and exploratory subagents every time they need to understand a project.

It solves a very practical problem: when an AI Agent works on a large codebase, much of the cost is not spent on changing code, but on finding where the relevant code lives. If every task starts with repeated searches, reads, and filtering, tokens, time, and tool calls are wasted. CodeGraph tries to turn the repository into a local map first, so the agent can ask the map before deciding which files to read.

What pain points does it address?

AI coding tools usually work well in small projects. There are few files, search is fast, and reading files is cheap. In larger projects, common problems appear:

The agent repeatedly calls grep, find, ls, and Read just to understand one module.
Exploratory subagents read many irrelevant files, while the main task context remains unclear.
Architecture questions spend too many tokens locating files.
Before changing a function, it is unclear who calls it and what it calls.
In web projects, URL routes and handler functions are not always obvious.

CodeGraph tries to move this “find the way first” work earlier. Once the project index exists, the agent can query related symbols, callers, callees, impact scope, and code snippets directly.

Installation

The project provides cross-platform installation scripts and does not require users to prepare Node.js manually:

`1`	`curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh \| sh`

On Windows PowerShell:

`1`	`irm https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.ps1 \| iex`

If you already have a Node environment, you can use npm directly:

`1`	`npx @colbymchenry/codegraph`

Or install it globally:

`1`	`npm i -g @colbymchenry/codegraph`

The installer detects and configures installed agents such as Claude Code, Cursor, Codex CLI, opencode, and Hermes Agent. It writes the relevant MCP server configuration and instruction files so those tools know when to call CodeGraph.

Initializing a project

After installation, build an index inside the target project:

1
2

cd your-project
codegraph init -i

This command creates a project-level knowledge graph index. The README notes that as long as a .codegraph/ directory exists in the project, agents can automatically use CodeGraph tools.

To stop using it, you can remove the global configuration:

`1`	`codegraph uninstall`

That removes the MCP server configuration, instructions, and permissions written by the installer. The .codegraph/ index in the project is not deleted automatically. To remove the project index, use codegraph uninit.

Why it helps agents

Tools like Claude Code, Codex CLI, and Cursor often explore before making changes: find files, read entry points, inspect references, and follow call chains. For humans this feels like browsing a project. For models, it becomes a series of tool calls and context cost.

CodeGraph turns that into index queries. An agent can first use codegraph_context to find relevant entry points, symbols, and snippets, then use codegraph_explore or other tools to read the necessary details. The benefits are:

Fewer irrelevant files read.
Fewer search tool calls.
Faster discovery of relevant code.
Clearer impact scope before edits.
Easier answers to architecture questions in large repositories.

The README reports benchmark results across seven real open source repositories comparing runs with and without CodeGraph. On average, enabling CodeGraph reduced cost, tokens, latency, and tool calls. The exact numbers depend on project size, language, question type, and agent behavior, but the direction is clear: the larger the repository, the more valuable pre-indexing becomes.

Core capabilities

1. Smart context construction

One tool call can return entry points, related symbols, and code snippets, reducing the need for the agent to launch many exploratory tasks before filtering the results. This is useful for architecture understanding, module location, and feature entry-point analysis.

2. Full-text search

CodeGraph uses FTS5 for full-text search, letting it quickly search names and text across the codebase. It does not replace every grep use case, but it gives the agent a more structured first stop.

3. Impact analysis

Before changing a function, class, method, or route, the agent can query callers, callees, and impact radius. This is especially useful for refactoring, bug fixing, and deleting old code, where missing upstream or downstream calls is the main risk.

4. Automatic freshness

The README says CodeGraph uses native filesystem events such as FSEvents, inotify, and ReadDirectoryChangesW, along with debounced auto-sync. In practice, the index updates as local code changes, so users do not need to rebuild it manually after every edit.

5. Multi-language support

The project lists support for more than 19 languages, including TypeScript, JavaScript, Python, Go, Rust, Java, C#, PHP, Ruby, C, C++, Swift, Kotlin, Dart, Lua, Luau, Svelte, Liquid, and Pascal / Delphi.

That makes it suitable for multi-language repositories and full-stack projects, not just one language.

6. Web route awareness

CodeGraph also detects route files and route declarations in many web frameworks, connecting URL patterns with handler functions. The README mentions Django, Flask, FastAPI, Express, NestJS, Laravel, Rails, Spring, Gin, Axum, ASP.NET, Vapor, React Router, SvelteKit, and others.

This is practical because the real entry point of many web projects is not an obvious main function, but routes, controllers, handlers, views, or resolvers. If an agent can first understand the URL-to-handler relationship, it can understand business flow much faster.

Local-first design

CodeGraph emphasizes being 100% local. It does not require an API key or external service. Index data is stored in a local SQLite database.

For enterprise projects, private repositories, or sensitive code, this matters. The concern with AI coding tools is often not only “can they find the code?”, but “will the code structure and index be sent elsewhere?” CodeGraph is positioned as local indexing, local querying, and local service for agents.

Of course, local indexing also means considering disk usage, indexing time, file watching, and project size. Very large repositories still require resources for initial indexing and later synchronization.

Suitable scenarios

CodeGraph is a good fit for:

Large codebases where architecture and call-chain questions are common.
Teams using Claude Code, Codex CLI, Cursor, or similar agents for code understanding and edits.
Reducing random file reads, broad searches, and repeated exploration by agents.
Analyzing impact before code changes.
Web projects with complex routing, where URL-to-handler lookup matters.
Teams that want a more stable local project index for AI agents.

For a small project with a few dozen files, normal search may be enough and CodeGraph’s advantage may not be obvious. It is most valuable in medium-to-large repositories and workflows where agents do a lot of exploration.

Things to watch out for

First, CodeGraph is not a substitute for code review or testing. It helps agents find relevant code faster, but it does not guarantee that their changes are correct.

Second, index quality affects results. If a project has complex structure, lots of generated code, mixed languages, or unignored build artifacts, the index may become noisy. Before using it seriously, check .gitignore, project layout, and indexing scope.

Third, MCP configuration and agent instructions matter. The README also warns that CodeGraph helps only when it is queried properly. If an agent ignores it and still reads many files directly, pre-indexing becomes extra overhead.

Fourth, even though it is local, permissions still matter. The installer writes agent configuration and permission lists. In team environments, review those configurations centrally.

Summary

CodeGraph can be understood simply: it gives AI agents a local map of the codebase. It does not make the model smarter; it helps the model get less lost.

When tools like Claude Code, Codex CLI, and Cursor face large repositories, the expensive part is often exploration. CodeGraph uses pre-indexed symbol relationships, call graphs, route graphs, and full-text search to handle “where is the code?” earlier, leaving more budget for understanding and editing.

If you already use AI coding tools in real projects and often see the agent read many files without finding the point, CodeGraph is worth trying. It represents an important direction for AI coding tools: not only stronger models, but better local code context for those models.

References:

GitHub project: https://github.com/colbymchenry/codegraph

What is oh-my-pi? An AI coding assistant that connects the terminal, IDE, and debugger

Sat, 23 May 2026 19:02:20 +0800

oh-my-pi is an AI Coding Agent for the terminal and editor. It is a fork of Mario Zechner’s Pi project, extended by can1357. Its goal is not just to provide a command-line chat UI, but to connect file reading, code search, structured edits, LSP, debuggers, browsers, subagents, and multiple model providers into one coding workflow.

From the project README, it feels more like an AI coding tool layer than a simple assistant: you can use it interactively in the terminal, connect editors through ACP, or embed it in Node projects through the SDK. For people already using Claude Code, Codex CLI, Cline, Cursor, or other agent tools, the interesting part is that oh-my-pi turns many abilities that usually live in separate tools into one built-in tool surface.

What problem is it trying to solve?

For many AI coding tools, the weak point is not the model itself, but the tool interface around it. When a model wants to change code but only has rough full-file reads, fragile string replacement, and one-off shell commands, the toolchain amplifies failure.

oh-my-pi tries to reduce those common points of friction:

File reads prefer structured summaries instead of dumping whole files into context.
Search, glob, find, syntax highlighting, and token counting are implemented natively where possible, reducing dependence on external commands.
Code writes can use LSP so renames, references, and file moves behave more like IDE operations.
Debugging can use DAP tools such as lldb, dlv, and debugpy, instead of relying only on logs and guesses.
Complex tasks can be split across subagents and returned as structured results.
Edits use content anchors and previews to reduce the chance of a bad patch landing directly on disk.

These choices show that the focus is not “can the model answer?”, but “can the model reliably complete a real code change?”

Installation

The project provides several installation paths. On macOS and Linux, you can use the install script:

`1`	`curl -fsSL https://omp.sh/install \| sh`

If you use Bun, the README recommends installing the npm package globally:

`1`	`bun install -g @oh-my-pi/pi-coding-agent`

On Windows PowerShell:

`1`	`irm https://omp.sh/install.ps1 \| iex`

The README also mentions pinning versions with mise:

`1`	`mise use -g github:can1357/oh-my-pi`

Before installing, check the Bun version requirement. The README lists macOS, Linux, and Windows support, and requires bun >= 1.3.14.

Capabilities worth watching

1. Tool calling goes beyond shell commands

oh-my-pi includes tools for file reads, search, writes, edits, AST edits, browser use, task splitting, debugging, and LSP. The README mentions 32 built-in tools, 13 LSP operations, and 27 DAP operations.

That means the agent does not have to wrap everything as command-line output. Reference lookup can go through LSP, PRs and issues can be read through a unified file-like interface, and web pages or PDFs can be converted into Markdown with link structure intact before being passed to the model.

2. LSP integration is useful for real codebases

In large projects, renaming and moving files often breaks re-exports, aliased imports, barrel files, or cross-directory references. The oh-my-pi README highlights that write paths can go through LSP. For example, file renames use workspace/willRenameFiles, making edits closer to semantic IDE operations.

This is useful for everyday refactoring in TypeScript, Rust, Go, Python, and similar projects, especially in cases where manual edits are possible but easy to miss.

3. The debugger is a first-class tool

Many AI coding flows still debug by adding logs, rerunning, and reading output. oh-my-pi connects DAP debuggers to the tool surface. The README gives examples with C programs using lldb, Go services using dlv, and Python processes using debugpy.

That changes how an agent handles bugs: it can pause a process, inspect stack frames, read local variables, and then decide what to do next, instead of guessing from error text alone.

4. Hashline editing reduces patch failures

The project emphasizes Hashline, an editing approach based on content anchors. The goal is to let the model point to the content it wants to change instead of repeatedly emitting large diffs. This reduces edit failures caused by whitespace, stale context, or failed string matching.

For agent tools, this matters a lot. Even a capable model feels clumsy if the write interface keeps failing and forcing retries.

5. Subagents and workspace isolation

The README introduces a task subagent capability: a task can be split across isolated workers, and results are returned as structured objects. The project also includes workspace isolation logic for parallel tasks, branch exploration, and avoiding overlapping edits.

This fits code review, migrations, bulk fixes, and test investigation. The value is not only speed; it is also cleaner separation between different exploration paths.

6. It can inherit existing rules and configs

On first run, oh-my-pi can read rules and configuration left by other tools, including .claude, .cursor, .windsurf, .gemini, .codex, .cline, .github/copilot, and .vscode.

That is practical. Many teams have already written rules for several AI tools. Rewriting them for every new tool is expensive, so oh-my-pi tries to reuse what is already on disk.

Four entry points

The project provides four main ways to use it:

Interactive TUI: run omp directly in the terminal.
One-shot command: use omp -p to send a single prompt.
Node SDK: embed it in a Node or TypeScript project through @oh-my-pi/pi-coding-agent.
RPC / ACP: connect other programs and editors through stdio or Agent Client Protocol.

This means it is not only for individual terminal users. It also leaves room for IDEs, plugins, automation platforms, and internal tools.

Who should try it?

oh-my-pi is a good fit for:

Developers who often edit, debug, and review code in the terminal.
People already using AI Coding Agents but unhappy with file reading, patching, search, or debugging reliability.
Developers who want to connect an agent to an editor, RPC layer, or Node service.
Users who need to switch between multiple models and providers in one tool.
Tool builders interested in LSP, DAP, AST editing, and subagent workflows.

If you only want a chat-style coding assistant that works immediately, the learning curve may feel high. It is better suited to people willing to understand the toolchain and treat the agent as a configurable development environment.

What to keep in mind

First, oh-my-pi is still a fast-moving open source project. Commits are frequent, and there are many issues and pull requests, so installation and usage may change.

Second, its capabilities depend heavily on your local environment. LSP, debuggers, Bun, model-provider authentication, terminal setup, and Windows or Unix differences can all affect the experience.

Third, having many built-in tools does not mean every scenario should enable everything. In practice, it is better to enable the tools needed for the task and configure rules, permissions, and workspace boundaries clearly.

Fourth, an AI Agent can write code, but it can also change the wrong code. Even with previews and content-anchored edits, important projects still need version control, tests, and human review.

Summary

The interesting part of oh-my-pi is not that it is another AI terminal shell. It is that it reorganizes the tool layer that often holds AI coding back: file reading, search, editing, LSP, debugging, browser access, subagents, and SDK integration all sit inside one agent workflow.

It is worth watching for people who care about AI coding infrastructure, and for developers comparing different Coding Agent approaches. The competition in AI coding tools is no longer just about model answer quality. It is also about who can connect models reliably to real codebases, real debugging workflows, and real team rules. oh-my-pi is an ambitious open source attempt in that direction.

References:

GitHub project: https://github.com/can1357/oh-my-pi
Official site: https://omp.sh/
SDK documentation: https://omp.sh/docs/sdk

Graphify Solves Claude Code's Biggest Limitation: Turning a Codebase into an AI-Queryable Knowledge Graph

Thu, 21 May 2026 08:02:32 +0800

safishamsi/graphify is a knowledge graph tool for AI coding assistants. Its goal is direct: take the code, docs, SQL schemas, scripts, papers, images, video, and audio inside a project folder, turn them into a queryable knowledge graph, and stop AI assistants from relying only on grep, full-file reading, or ad hoc search to understand a project.

Project link: safishamsi/graphify

At the time of writing, the GitHub page shows about 50.2k stars and 5.4k forks, with an MIT license. The README describes it like this: type /graphify inside your AI coding assistant, and it maps the entire project into a queryable knowledge graph.

The Core Problem It Solves

AI coding assistants are becoming stronger, but in real codebases they still frequently run into several problems:

They do not know how key modules connect.
They read many files but do not form an overall architecture map.
Search finds text, but not upstream and downstream dependencies.
Code, database schemas, docs, and infrastructure configuration are scattered across different places.
In team collaboration, each person may have a different mental model of the project structure.

Graphify tries to add a “memory layer” to the project. It connects code entities, documentation concepts, database tables, configuration, design notes, and cross-file relationships so the AI assistant can query the graph instead of scanning files from scratch every time.

Minimal Usage

Graphify’s minimal workflow is simple. After installation, type this inside your AI coding assistant:

`1`	`/graphify .`

In PowerShell, the leading / is treated as a path separator, so on Windows PowerShell use:

`1`	`graphify .`

After running, it generates a graphify-out/ directory with three core files:

graphify-out/
├── graph.html
├── GRAPH_REPORT.md
└── graph.json

These files serve different purposes:

graph.html: an interactive graph you can open in a browser, with clickable nodes, filters, and search.
GRAPH_REPORT.md: highlights, key concepts, surprising connections, and suggested questions.
graph.json: the full graph, which can be queried later without rereading all files.

To generate a more readable architecture page with Mermaid call-flow diagrams, run:

`1`	`graphify export callflow-html`

Installation and Platform Support

Graphify’s PyPI package name is graphifyy, with a double y. The README specifically warns that other graphify* packages on PyPI are not affiliated with the project, although the CLI command is still graphify.

The recommended installation method is:

`1`	`uv tool install graphifyy`

Alternatives:

1
2

pipx install graphifyy
pip install graphifyy

Then register it with your AI assistant:

`1`	`graphify install`

The project supports many platforms, including Claude Code, Codex, OpenCode, GitHub Copilot CLI, VS Code Copilot Chat, Aider, Cursor, Gemini CLI, Kimi Code, Kiro, and Google Antigravity. Different platforms can use different install commands, for example:

graphify install --platform codex
graphify install --platform gemini
graphify cursor install
graphify antigravity install

Codex users also need to add this under [features] in ~/.codex/config.toml:

`1`	`multi_agent = true`

The README also notes that Codex uses $graphify, not /graphify.

What Files It Handles

Graphify supports a wide range of input types.

For code, it supports 31 languages, including Python, TypeScript, JavaScript, Go, Rust, Java, C/C++, Ruby, C#, Kotlin, Scala, PHP, Swift, Lua, Zig, PowerShell, SQL, Shell, JSON, and more.

For documents, it supports:

.md
.mdx
.qmd
.html
.txt
.rst
.yaml
.yml

Optional dependencies extend it further:

pip install "graphifyy[pdf]"
pip install "graphifyy[office]"
pip install "graphifyy[video]"
pip install "graphifyy[mcp]"
pip install "graphifyy[neo4j]"
pip install "graphifyy[sql]"
pip install "graphifyy[all]"

Here, pdf is for PDF extraction, office for .docx and .xlsx, video for video and audio transcription, mcp for an MCP stdio server, neo4j for pushing to Neo4j, and sql for SQL schema extraction.

Why the Report Matters

GRAPH_REPORT.md is not a normal summary. It extracts relationships inside the project that are especially useful for AI assistants.

The README mentions report contents such as:

God nodes: the most-connected core concepts in the project.
Surprising connections: unexpected links across files or modules.
The why: design rationale extracted from comments, docstrings, and design docs.
Suggested questions: questions the graph is particularly well suited to answer.
Confidence tags: relationships are labeled EXTRACTED, INFERRED, or AMBIGUOUS.

This is important. Normal search only tells you “where this word appears.” A graph can answer “which modules, configs, tables, and docs this concept is connected to.” For large codebases, that is closer to architecture understanding than simple full-text search.

Common Commands

Common Graphify commands include:

/graphify .
/graphify ./docs --update
/graphify . --cluster-only
/graphify . --no-viz
/graphify . --wiki
graphify export callflow-html
/graphify query "what connects auth to the database?"
/graphify path "UserService" "DatabasePool"
/graphify explain "RateLimiter"

You can also add a paper or video to the graph:

1
2

/graphify add https://arxiv.org/abs/1706.03762
/graphify add <youtube-url>

For PR-assisted analysis:

graphify prs
graphify prs 42
graphify prs --triage
graphify prs --conflicts

These commands fit code review scenarios: identify which graph communities a PR affects, whether it risks conflicts with other PRs, and which review queues deserve priority.

MCP, Neo4j, and CI

Graphify is not only an HTML graph generator. It can also expose the graph to AI assistants for repeated tool use.

For example, start an MCP server:

`1`	`python -m graphify.serve graphify-out/graph.json`

The MCP server provides capabilities such as query_graph, get_node, get_neighbors, shortest_path, list_prs, get_pr_impact, and triage_prs.

It also supports Neo4j export or push:

1
2

/graphify ./raw --neo4j
/graphify ./raw --neo4j-push bolt://localhost:7687

For team collaboration, the README suggests committing graphify-out/ so everyone on the team starts with the same project map. You can also run:

`1`	`graphify hook install`

This rebuilds the graph after each git commit and sets up a merge driver so graph.json does not get left with conflict markers when multiple people commit in parallel.

Privacy and Cost

Graphify’s README is fairly clear about privacy boundaries.

Code files are parsed locally through tree-sitter and do not trigger API calls. Video and audio can be transcribed locally with faster-whisper. Docs, PDFs, and images used for semantic extraction go through your AI assistant’s model API.

For headless graphify extract, you may need these environment variables:

ANTHROPIC_API_KEY
GEMINI_API_KEY
GOOGLE_API_KEY
OPENAI_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY
OLLAMA_BASE_URL

Local Ollama, AWS Bedrock, and Claude Code CLI can also be used as backends. The README also states that the project has no telemetry, usage tracking, or analytics.

In practice, remember that local code parsing does not mean everything stays offline. When docs, PDFs, images, or cloud models are involved, you still need to consider the backend, API keys, enterprise compliance, and data boundaries.

Suitable Scenarios

Graphify is suitable for several types of users:

Developers who want Claude Code, Codex, Cursor, and Gemini CLI to better understand project structure.
People who need to quickly understand a large unfamiliar codebase.
Teams that need to analyze code, SQL schemas, docs, and configuration together.
People doing architecture review, PR review, or refactor impact analysis.
Teams that want to expose project knowledge as an MCP tool for Agents.
Technical leads who want to keep a “project map” for the team.

It is not necessary for every project. For small scripts, one-off demos, or very simple repositories, normal search and README files may be enough. Graphify’s value shows up more clearly in projects with many modules, many docs, team collaboration, and frequent AI assistant involvement.

Summary

Graphify matters because it moves AI coding assistants from “temporarily reading files” toward “a long-lived, queryable project knowledge graph.”

For developers, it does not replace the IDE, search, or LSP. It adds a structured memory layer for AI assistants: which modules matter, which concepts are tightly connected, which docs explain design rationale, and which communities a PR may affect. As Codex, Claude Code, Gemini CLI, Antigravity, and similar Agent tools become more common, this kind of project graph layer will become increasingly useful.

References:

GitHub: safishamsi/graphify

What Is Vercel AI SDK? A Unified Toolkit for TypeScript Developers Building AI Apps

Sun, 17 May 2026 23:07:38 +0800

vercel/ai is the open-source AI SDK maintained by Vercel.

Its positioning is clear: it gives TypeScript developers a unified toolkit for building AI applications and AI Agents. It comes from the team behind Next.js, but it is not limited to Next.js. It also supports React, Svelte, Vue, Angular, and runtimes such as Node.js.

Project link: https://github.com/vercel/ai

If you are building a chat app, AI writing tool, RAG application, tool-calling Agent, streaming interface, or a product that needs to connect multiple model providers behind one application, Vercel AI SDK is worth a close look.

The Core Problem It Solves

When building AI apps today, one of the biggest headaches is not whether you can call a model. It is that different model providers have different APIs, streaming formats, tool-calling conventions, error behavior, and frontend state-management needs.

For example:

OpenAI has its own SDK and response formats.
Anthropic has its own message structure.
Google, xAI, Mistral, DeepSeek, Groq, and others all differ.
Streaming output requires chunk handling.
Tool calling requires structured requests initiated by the model.
Chat UI also needs messages, loading states, cancellation, retry, and error display.

If every provider gets its own handwritten adapter, the project becomes complex very quickly.

Vercel AI SDK tries to hide those differences behind a unified API. Developers write the app against one interface and connect different models through Providers.

Unified Provider Architecture

One key feature of Vercel AI SDK is that it is provider-agnostic. It is not tied to one model vendor.

It can access OpenAI, Anthropic, Google, and other model providers through a unified API. The project README also notes that AI SDK uses Vercel AI Gateway by default, making it easier to reach multiple mainstream providers.

That is useful in real engineering projects.

Many AI products eventually depend on more than one model:

Some tasks need strong reasoning models.
Some tasks need cheap, fast models.
Some tasks require multimodal models.
Some tasks require long context.
Some tasks require local or private deployment.

A unified provider architecture makes model switching, gray releases, cost control, and fallback strategies easier.

Streaming Output Is Key to Frontend UX

One major UX difference between AI apps and traditional APIs is that responses can be long.

If users must wait for a full answer before seeing anything, chat tools, writing tools, and coding assistants feel slow. Streaming output lets text appear gradually, so users see progress sooner.

Vercel AI SDK provides fairly complete abstractions for streaming generation. Developers do not need to handle low-level event streams from scratch. They can use the SDK’s generation and streaming APIs to connect model output to frontend UI.

This is especially convenient for Next.js and React applications.

An AI chat interface looks simple, but in practice it must handle:

Message lists.
User input.
Server requests.
Streaming token display.
Loading states.
Error states.
Stopping generation.
Regeneration.

These are exactly the kinds of repetitive work AI SDK tries to reduce.

Tool Calling and Agent Scenarios

As AI apps move from “chatting” to “doing things”, tool calling becomes increasingly important.

The model may need to call external functions instead of only returning natural language:

Query a database.
Search documents.
Call business APIs.
Read order status.
Generate charts.
Create calendar events.
Modify project files.

Vercel AI SDK supports tool-calling capabilities, allowing developers to define tools, parameters, and execution logic, then let the model request those tools when appropriate.

This is one reason it has evolved from a “chat UI SDK” into a broader toolkit for AI apps and Agents.

Still, tool calling is not magic. Real projects must also handle:

Parameter validation.
Permission boundaries.
Tool-call logs.
Idempotency.
Timeouts and retries.
Human confirmation.
Restrictions for sensitive actions.

AI SDK can help with interfaces and flow, but developers still need to design the safety boundaries.

UI Integration

Vercel AI SDK is friendly to frontend frameworks.

It provides not only core generation APIs, but also abstractions around chat, completion, message state, and streaming UI. For teams using Next.js and React, this can remove a lot of boilerplate.

But it is not only for Vercel deployments.

If your project is built with TypeScript, or your backend runs on Node.js, AI SDK can still serve as the model-calling and streaming layer. Whether you deploy to Vercel depends on your architecture, team habits, and infrastructure choices.

Skill for Coding Agents

The vercel/ai README includes an interesting suggestion: if you use coding agents such as Claude Code or Cursor, you can add the AI SDK skill to your repository.

The example command is:

`1`	`npx skills add vercel/ai`

This shows that Vercel understands AI SDK users are not only human developers, but also coding agents.

When an agent modifies a project that uses AI SDK, a dedicated skill in the repository can help it understand SDK conventions, common APIs, project structure, and best practices, reducing the chance of messy code changes.

This direction is worth watching.

In the future, open-source projects may provide not only README files and docs, but also structured skill instructions for AI coding agents. For complex SDKs, that could become a new developer-experience entry point.

Suitable Projects

Vercel AI SDK is a good fit for:

AI chat apps based on Next.js or React.
Writing, Q&A, support, and coding assistants that need streaming output.
AI products that need multiple model providers.
Teams building quick RAG or document Q&A prototypes.
Apps that need tool calling, function calling, or lightweight Agent capabilities.
Teams already using TypeScript and Node.js.

It is especially suitable for frontend and full-stack developers. The hard part of many AI apps is not only calling a model, but turning model output into a stable, smooth, interactive product experience.

What It Is Not For

If your project is mainly a Python backend, deep-learning training workflow, model fine-tuning system, or low-level inference service, Vercel AI SDK may not be the core tool.

It is an application-layer SDK, not a model-training framework.

If you need to:

Train your own model.
Manage GPU inference clusters.
Run low-level batch inference.
Deeply control tokenizer behavior, KV cache, quantization, and inference engines.

Then you should look at PyTorch, vLLM, SGLang, TensorRT-LLM, llama.cpp, or cloud inference services.

Vercel AI SDK is closer to the application layer that connects model capabilities to products.

What to Watch For

First, do not assume a unified API means all providers are identical.

Different providers still differ in capabilities, context length, tool-calling formats, streaming details, error types, and pricing. A unified SDK reduces engineering friction, but it does not erase model differences.

Second, control costs.

Once an AI app is online, streaming chats, retries, tool calls, RAG retrieval, and multi-model fallbacks can all increase cost. Rate limits, caching, logs, and budget monitoring are necessary.

Third, handle safety boundaries.

If a model can call tools, you must restrict what those tools can do. Do not let the model directly execute high-risk operations, and do not expose secrets, database write permissions, or production operations to it without controls.

Fourth, keep observability.

When an AI app fails, frontend errors are not enough. You need to know the user input, selected model, tool calls, response time, token usage, error type, and final output.

Summary

vercel/ai is not a new model, and it is not just a chat component.

It is closer to infrastructure for TypeScript AI application development: unified Providers, streaming output, tool calling, frontend state management, and Agent scenarios all live inside one open-source SDK.

For teams already using Next.js, React, TypeScript, and Node.js, it can significantly reduce the engineering cost of going from “the model API runs” to “the product experience works”.

But it is not a universal layer. Model selection, permission design, cost control, logging, monitoring, and business safety still belong to the developer.

If you want to build AI applications rather than train models, Vercel AI SDK is a toolkit worth trying early.

References

Bun: JavaScript runtime, package manager, test runner, and bundler in one tool

Sun, 17 May 2026 17:42:25 +0800

Bun is an open source JavaScript / TypeScript all-in-one toolchain from oven-sh.

It is not just trying to be a faster Node.js replacement. It puts the runtime, package manager, script runner, test runner, and bundler behind the same bun command. For frontend and Node.js developers, the appeal is simple: install fewer tools, wait less during installation and builds, and complete many common tasks with one command.

Project: https://github.com/oven-sh/bun

Bottom line

Bun is best for people who want to simplify the JavaScript toolchain.

It can:

Run JavaScript, TypeScript, JSX, and TSX.
Act as a Node.js-compatible runtime.
Replace npm / yarn / pnpm for package management.
Run scripts from package.json.
Execute tests.
Bundle frontend or backend code.
Use bunx to run commands from npm packages.
Provide built-in APIs such as Bun.serve, bun:sqlite, Bun.sql, Bun.redis, and Bun.s3.

Its clearest value is developer experience: fast installs, fast startup, unified commands, and TypeScript / JSX that work out of the box.

But Bun is not something every project should switch to immediately. Large Node.js applications, projects with many native extensions, and production services with strict stability requirements still need careful compatibility, build, test, and deployment validation.

What Bun is

According to the official README, Bun is an all-in-one toolkit for JavaScript and TypeScript applications. It ships as a single executable named bun.

At its core is the Bun runtime: a fast JavaScript runtime intended as a drop-in replacement for Node.js. Bun is written in Zig, built on JavaScriptCore, and optimized for startup time and memory usage.

That means you can run:

`1`	`bun run index.tsx`

TypeScript and JSX can run without extra setup.

The same bun command also includes:

test runner
script runner
Node.js-compatible package manager
bundler
package runner

Common commands include:

bun test
bun run start
bun install <pkg>
bunx cowsay 'Hello, world!'

A typical project may otherwise include node, npm, pnpm, tsx, jest, vitest, webpack, esbuild, and ts-node. Bun tries to absorb many of those high-frequency paths into one tool.

Installation

Bun supports Linux, macOS, and Windows on x64 and arm64.

The official install script is:

`1`	`curl -fsSL https://bun.com/install \| bash`

Windows:

`1`	`powershell -c "irm bun.sh/install.ps1 \| iex"`

It can also be installed through npm:

`1`	`npm install -g bun`

macOS Homebrew:

1
2

brew tap oven-sh/bun
brew install bun

Docker:

1
2

docker pull oven/bun
docker run --rm --init --ulimit memlock=-1:-1 oven/bun

Linux users should note the kernel requirement. The README strongly recommends Linux kernel 5.6 or newer, with 5.1 as the minimum.

Upgrade to the latest version:

`1`	`bun upgrade`

Upgrade to canary:

`1`	`bun upgrade --canary`

Canary is usually not a good choice for production unless you are validating a new feature or investigating a specific bug.

Why Bun is fast

Bun’s speed comes from several layers.

First, runtime startup is fast. Many CLI tools and development scripts are not limited by long CPU work, but by process startup, module loading, TypeScript transpilation, and dependency resolution. Bun optimizes these paths.

Second, package management is fast. bun install aims to replace npm / yarn / pnpm installation workflows. It uses a global cache and its own lockfile, which can noticeably reduce waiting time in dependency-heavy projects.

Third, TypeScript / JSX work out of the box. Many projects only need to run a .ts or .tsx script. Traditional Node.js setups need tsx, ts-node, Babel, or a build step. Bun can run these files directly and reduces glue tooling.

Fourth, built-in tools reduce process and configuration switching. Testing, scripts, bundling, and runtime execution all live in one tool.

Still, “Bun is fast” does not mean every project will be faster. Real results depend on dependency types, script logic, test framework, build configuration, Node.js API usage, and CI cache strategy.

Package management: replacing npm / yarn / pnpm

Bun can install dependencies directly:

`1`	`bun install`

Add a dependency:

`1`	`bun add react`

Add a development dependency:

`1`	`bun add -d typescript`

Remove a dependency:

`1`	`bun remove react`

Explain why a dependency exists:

`1`	`bun why react`

Security audit:

`1`	`bun audit`

When migrating from npm or pnpm, check:

Whether bun.lock is committed.
Whether CI uses bun install --frozen-lockfile.
Whether private registries and .npmrc are compatible.
Whether workspace behavior matches expectations.
Whether lifecycle scripts introduce security risk.
Whether pnpm-specific monorepo behavior can migrate smoothly.

Small projects can try it directly. Large monorepos should not switch everything at once; start with one package or a non-blocking CI job.

Running scripts and TypeScript

Bun can run scripts from package.json:

`1`	`bun run start`

It can also run files directly:

1
2

bun run index.ts
bun run index.tsx

This is useful for tool scripts such as:

scripts/build.ts
scripts/seed.ts
scripts/migrate.ts
scripts/check.ts

With Node.js, these often require a TypeScript loader or precompilation. Bun’s direct execution makes those scripts lighter.

If a script depends on Node.js-specific behavior, especially loaders, ESM/CJS edges, native modules, child processes, file watching, or edge APIs, it still needs testing.

Test runner

Bun includes a test runner:

`1`	`bun test`

It is suitable for small projects that want less Jest / Vitest configuration, and for moving some unit tests, tool tests, or library tests to a lighter runner.

When migrating tests, pay attention to:

expect behavior.
mock API differences.
snapshot behavior.
DOM test environment.
test discovery rules.
coverage output.
CI reporter support.

If a project deeply depends on Jest features, such as custom matchers, complex mocks, jsdom, babel-jest, or ts-jest, migration should be gradual. Let new modules use bun test while old suites remain on the existing framework.

Bundling and builds

Bun also provides a bundler:

`1`	`bun build ./src/index.ts --outdir ./dist`

It can be used for frontend bundles, backend scripts, CLI tools, and libraries. Bun’s docs also cover loaders, plugins, macros, CSS, HTML, HMR, minifier, and single-file executables.

Good early candidates:

Small frontend tools.
Node.js CLI projects.
Internal scripts.
Single-file services.
Projects that do not depend on complex webpack loaders.

Be careful with:

Complex webpack plugin chains.
Large Vite plugin setups.
Deep Babel transformations.
Special CSS / asset pipelines.
Micro-frontends and module federation.
Projects with strict requirements for hashes, chunks, and compatibility.

Bun’s bundler is attractive, but migrating build tools is usually riskier than changing the package manager. Validate it separately.

Running HTTP services

Bun provides Bun.serve for HTTP services:

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello from Bun")
  },
})

This is convenient for small APIs, internal services, webhook receivers, and edge-style services. Bun also provides APIs such as WebSockets, Workers, Streams, SQLite, PostgreSQL, Redis, S3, and TCP/UDP sockets.

If you already use Express, Fastify, NestJS, Next.js, Hono, Elysia, or another framework, check their Bun compatibility before rewriting anything.

A practical path is:

Use Bun first for development scripts and package management.
Then try Bun for tests.
Only later evaluate whether the production runtime should move to Bun.

Runtime migration needs the most care because it directly affects production behavior.

Relationship with Node.js

One of Bun’s goals is to be a drop-in replacement for Node.js, but compatibility is not the same as complete equivalence.

The Node.js ecosystem has accumulated many subtle behaviors around:

CJS / ESM interop.
Node built-in modules.
Native extensions.
npm lifecycle scripts.
Filesystem edge behavior.
stream and Buffer details.
worker / child_process.
debugging and profiling.

Bun is improving compatibility quickly, but production migration should be judged by tests.

Practical questions:

Do your tests pass under Bun?
Do key dependencies support Bun?
Are build artifacts equivalent?
Are CI and local behavior consistent?
Do you have monitoring and rollback in production?
Are Docker images and deployment scripts stable?

Replacing only the package manager is lower risk. Replacing the production runtime is much higher risk.

Suitable projects

Bun fits well for:

New small JavaScript / TypeScript projects.
Internal tools and scripts.
CLI projects.
CI jobs that need faster dependency installation.
Frontend projects that want less toolchain complexity.
Scripts and services where startup speed matters.
Developers who want TypeScript to run out of the box.

Use more caution with:

Very large monorepos.
Projects deeply tied to pnpm workspace behavior.
Services with many Node.js native extensions.
Frontend builds with highly customized pipelines.
Backends that require strict production runtime consistency.
Test suites deeply tied to Jest.

A conservative but practical strategy is to treat Bun as a development tool first, not as an immediate replacement for every production runtime.

Migration advice

To try Bun in an existing project:

Install Bun locally.
Run bun install and inspect dependency installation.
Commit or temporarily keep bun.lock to avoid lockfile confusion.
Try bun run <script> on common scripts.
Migrate a small number of tests with bun test.
Add a non-blocking Bun job in CI.
If compatibility looks good, consider changing the main install flow.
Evaluate production runtime migration last.

For team projects, keep a rollback path:

Preserve the old npm / pnpm / yarn flow during migration.
Run both flows in CI for a while.
Do not change runtime, package manager, test framework, and bundler in the same change.
Split migration into small, verifiable steps.

This is slower, but it avoids mixing too many problems together.

Common commands

Install:

`1`	`curl -fsSL https://bun.com/install \| bash`

Upgrade:

`1`	`bun upgrade`

Install dependencies:

`1`	`bun install`

Add a dependency:

`1`	`bun add lodash`

Run a script:

`1`	`bun run dev`

Run TypeScript directly:

`1`	`bun run scripts/build.ts`

Test:

`1`	`bun test`

Bundle:

`1`	`bun build ./src/index.ts --outdir ./dist`

Run a package command:

`1`	`bunx cowsay 'Hello, world!'`

Summary

Bun’s value is not just “faster than Node.js.” More importantly, it pulls many scattered JavaScript / TypeScript development tools into one bun command: runtime, package manager, script runner, test runner, and bundler.

For new projects and internal tools, this integrated experience can be pleasant: fast installs, fast startup, less configuration, and direct TypeScript / JSX execution. For large existing projects, Bun is better introduced through low-risk areas first, such as package installation, scripts, and selected tests, before validating builds and runtime behavior.

If Node.js toolchain installation speed, configuration fragments, and slow test startup often bother you, Bun is worth a serious try. But production migration still comes back to basic engineering judgment: do tests pass, are dependencies compatible, is CI stable, and do you have rollback?

References:

Godot Game Development Beginner Guide: From Nodes and Scenes to Your First 2D Game

Sun, 17 May 2026 12:37:30 +0800

Godot is an open-source game engine suitable for 2D games, independent prototypes, and medium-scale 3D projects.

Its biggest strengths are that it is lightweight, open source, fast to start, and built around a clear node-and-scene model. For beginners, Godot is usually easier to approach than Unity. For independent developers, it is also easier to keep projects small and controllable.

This guide keeps the path simple: understand nodes and scenes, learn basic GDScript, then build a small 2D game that connects input, physics, collision, UI, audio, and export.

Bottom line

Do not start by learning every engine feature.

A better path is:

Start with 2D, not 3D.
Understand nodes and scenes before complex architecture.
Learn GDScript first, not C#.
Build one small game that can start, fail, and restart.
Then add animation, audio, UI, levels, and export.

Completing one tiny game teaches more than watching many unrelated tutorials.

Who Godot is good for

Godot is a strong fit if you:

want to learn game development from zero,
want to build 2D indie games,
need fast gameplay prototypes,
do not want a heavy commercial engine workflow,
want to understand how engines organize game objects,
have some Python or JavaScript experience and want an easy scripting language.

Unity and Unreal still have advantages for large commercial pipelines, asset stores, mobile monetization SDKs, or high-end 3D visuals. But for learning and making your own games, Godot is an excellent starting point.

Installation and project creation

Godot is simple to install: download it from the official website, unzip it, and run it.

For the first project:

Use the default renderer.
Use an English project name.
Avoid paths with too many spaces or non-ASCII characters.
Use Git from the beginning.

A simple project name:

`1`	`first-godot-game`

Learn the editor areas first: Scene tree, FileSystem, Inspector, Script editor, and 2D / 3D viewport.

Core idea: nodes and scenes

The two most important Godot concepts are nodes and scenes.

Nodes are functional units:

Node2D: base 2D object.
Sprite2D: displays an image.
CollisionShape2D: collision shape.
CharacterBody2D: controllable character.
Camera2D: 2D camera.
AudioStreamPlayer: audio playback.
Label: text display.

A scene is a reusable group of nodes. A player can be a scene, an enemy can be a scene, and a level can be a scene.

For example:

Player (CharacterBody2D)
├── Sprite2D
├── CollisionShape2D
└── Camera2D

The player handles movement, Sprite2D displays the image, CollisionShape2D handles collision, and Camera2D follows the player.

What to build first

Do not start with an RPG, open world, networking, or complex platformer.

Build a tiny 2D dodging game:

The player moves up, down, left, and right.
Enemies spawn from screen edges.
Touching an enemy means failure.
Survival time becomes score.
There is a start button, game-over screen, and restart.

This small project covers movement, input, collision, spawning, UI, timers, audio, and scene reloads.

Player movement

Use CharacterBody2D for a controllable player.

Attach a script to Player:

extends CharacterBody2D

@export var speed := 300.0

func _physics_process(delta):
    var direction := Vector2.ZERO

    direction.x = Input.get_axis("move_left", "move_right")
    direction.y = Input.get_axis("move_up", "move_down")
    direction = direction.normalized()

    velocity = direction * speed
    move_and_slide()

Then define input actions:

move_left  -> A / Left
move_right -> D / Right
move_up    -> W / Up
move_down  -> S / Down

Use input actions instead of hard-coded key codes. It makes keyboard, gamepad, touch, and remapping easier later.

Collision and physics

Common 2D nodes:

CollisionShape2D: defines collision shape.
Area2D: detects overlap and triggers.
CharacterBody2D: player or controlled character.
RigidBody2D: physics-driven object.
StaticBody2D: walls, floors, fixed obstacles.

For beginners: if you control movement manually, use CharacterBody2D. If you only need to detect contact, use Area2D.

Example:

1
2
3

func _on_body_entered(body):
    if body.name == "Player":
        get_tree().reload_current_scene()

Later, replace direct reloads with a game_over signal. For the first project, getting the loop working is more important.

Instancing enemies

Godot scenes can be used like prefabs.

If you have Enemy.tscn, spawn it from the main scene:

@export var enemy_scene: PackedScene

func spawn_enemy():
    var enemy = enemy_scene.instantiate()
    enemy.position = Vector2(800, randf_range(50, 550))
    add_child(enemy)

Add a Timer to call spawn_enemy() repeatedly.

UI and score

Use Control nodes for UI:

CanvasLayer: keeps UI fixed on screen.
Label: text.
Button: button.
Panel: background.
VBoxContainer / HBoxContainer: layout.

Simple survival score:

var score := 0.0

func _process(delta):
    score += delta
    $CanvasLayer/ScoreLabel.text = str(int(score))

Audio and feedback

Even simple games need feedback:

click sounds,
hit sounds,
score sounds,
failure sounds,
screen shake or flash,
button hover / pressed states.

Use AudioStreamPlayer:

`1`	`$HitSound.play()`

Functionality is only the first step. Good feedback makes the player feel the game responding.

Project organization

Start with clean folders:

res://
├── scenes/
│   ├── Main.tscn
│   ├── Player.tscn
│   └── Enemy.tscn
├── scripts/
│   ├── player.gd
│   └── enemy.gd
├── assets/
│   ├── sprites/
│   └── audio/
└── ui/
    └── GameOver.tscn

Do not dump everything into the root directory. Small games grow faster than expected.

Common beginner mistakes

Choosing the wrong node type.
Forgetting collision shapes.
Hard-coding keyboard keys.
Putting player, enemies, UI, audio, and level logic into one script.
Starting with a project that is too large.

A tiny finished game is more valuable than an abandoned big idea.

Suggested learning path

Editor basics.
Nodes and scenes.
GDScript basics.
Input actions.
2D movement.
Collision and Area2D.
Timer and spawning.
UI and score.
Audio and animation.
Export to desktop or web.

Godot vs Unity

Godot is comfortable for 2D indie games, teaching projects, and personal prototypes.

Unity still has stronger asset stores, commercial plugins, mobile ads, monetization SDKs, and mature team workflows.

Unreal is better for high-end 3D and advanced rendering.

For beginners, do not let engine choice become procrastination. The core skills are game loops, input, collision, feedback, scene organization, state management, and version control.

Completion checklist

You have really completed the first step when your game has:

player movement,
enemies or obstacles,
collision failure,
score or objective,
start screen,
game-over screen,
restart,
at least two sounds,
simple animation or visual feedback,
an exported playable build.

Summary

Godot’s entry point is not memorizing every feature. It is understanding how the engine organizes games: nodes form scenes, scenes form games, scripts drive behavior, signals connect events, and resources live in folders.

Start with a small 2D game. Once movement, collision, UI, audio, and restart work, then learn animation trees, TileMap, saving, state machines, 3D, shaders, and export optimization.

Ghostty Docs Quick Read: Installation, Configuration, and Daily Usage Notes

Fri, 15 May 2026 14:50:11 +0800

Ghostty is a new terminal emulator, but it is not simply “another faster terminal.” According to its official documentation, it tries to balance three goals at the same time: speed, features, and a native desktop experience. In other words, it wants GPU acceleration and solid rendering performance, while also feeling like a real local app on macOS and Linux instead of pushing every interaction into a custom-drawn interface.

If you currently use iTerm2, Kitty, Alacritty, WezTerm, or the system terminal, the most interesting part of Ghostty is not one isolated feature. It is the way it combines “works out of the box” with “deeply configurable.” The default configuration is already usable, but when you want to tune it further, the docs provide complete entry points for configuration files, themes, keybindings, fonts, Shell integration, and terminal control sequences.

Start with the Positioning

Ghostty’s core positioning can be summarized in three points:

It is a cross-platform terminal emulator, currently focused on macOS and Linux.
It uses platform-native UI: Swift, AppKit, and SwiftUI on macOS; Zig and GTK4 on Linux.
Its terminal core is libghostty, and the GUI applications are built around this shared core.

This design affects daily use. Tabs, splits, error prompts, window state restoration, system shortcuts, and similar features are not merely components that “look like a desktop app.” They try to follow the interaction conventions of each operating system. The default shortcuts on macOS and Linux also differ according to platform expectations.

Installation: Direct on macOS, Distribution-Dependent on Linux

The official prebuilt binaries mainly target macOS. The most common installation path is to download the .dmg, open it, and drag Ghostty into the Applications folder. Homebrew users can also use the community-maintained cask:

`1`	`brew install --cask ghostty`

Linux is more fragmented. The Ghostty docs separate package managers, community binaries, and source builds for different distributions. Arch, Alpine, Gentoo, NixOS, Snap, Solus, Void, and others all have their own paths. If a distribution has no official or trusted repository, the docs lean toward building from source rather than casually installing third-party binaries.

This matters especially on servers and workstations: a terminal emulator handles a large amount of input and output, clipboard data, links, SSH sessions, and local file paths. It is better to be conservative with the installation source, preferring the official macOS package, distribution repositories, or a build process whose source you can audit.

Configuration: Do Not Rush to Copy a Giant dotfiles Setup

Ghostty’s configuration philosophy is “usable with zero configuration.” The default font includes JetBrains Mono and Nerd Font support, so most users can work normally the first time they open it. The docs even suggest that if you must configure a non-subjective option to feel comfortable, it may be worth asking whether that behavior should become the default.

When you do need customization, Ghostty uses a text configuration file. The current configuration file name is config.ghostty, while older versions also support config. Common paths include:

$XDG_CONFIG_HOME/ghostty/config.ghostty
$XDG_CONFIG_HOME/ghostty/config
$HOME/.config/ghostty/config.ghostty
$HOME/.config/ghostty/config

On macOS, Ghostty also reads:

1
2

$HOME/Library/Application Support/com.mitchellh.ghostty/config.ghostty
$HOME/Library/Application Support/com.mitchellh.ghostty/config

The syntax is straightforward: key = value. For example:

font-family = JetBrains Mono
font-size = 14
theme = light:Rose Pine Dawn,dark:Rose Pine
keybind = ctrl+shift+t=new_tab

A practical suggestion: do not start by copying someone else’s full configuration. A steadier approach is to run it bare for a few days and change only three things at first: font family, font size, and theme. Once you actually feel friction around shortcuts, splits, windows, or Shell integration, add those settings one by one.

Documentation Lookup: Full Configuration Reference Is Available Locally

Ghostty has many configuration options, and the official docs collect them in the Option Reference. Besides the web page, you can query the reference locally after installation:

`1`	`ghostty +show-config --default --docs`

This command prints the default configuration and documentation to standard output, which is useful when piped into a pager:

`1`	`ghostty +show-config --default --docs \| less`

To list available fonts:

`1`	`ghostty +list-fonts`

To list built-in and available themes:

`1`	`ghostty +list-themes`

To view default keybindings:

`1`	`ghostty +list-keybinds --default`

These commands are more reliable than copying snippets from the web, because they come from the Ghostty version installed on your own machine.

Keybindings: Treat “Actions” as the Core Concept

Ghostty’s keybinding format is:

`1`	`keybind = trigger=action`

trigger is the key sequence, and action is the operation Ghostty performs. Creating a new tab, closing the current surface, reloading configuration, and jumping to a prompt are all actions. The model is clear: you are not “changing a menu item”; you are binding an input sequence to an action.

After changing configuration, you can reload it at runtime. The default shortcut is:

Linux: ctrl+shift+,
macOS: cmd+shift+,

Not every setting takes effect immediately. Some options only affect newly created terminals, while others require a full restart. If “the config is written but nothing changed,” check the documentation for that option before spending too much time suspecting syntax.

Themes and Fonts: Use Built-Ins First, Then Tune

Ghostty ships with many themes and supports switching themes according to the system light or dark mode:

`1`	`theme = light:Rose Pine Dawn,dark:Rose Pine`

Themes can also come from custom files. The docs are clear here: a theme file is essentially a Ghostty configuration file and can set many options, so do not casually use themes from untrusted sources.

For fonts, font-family can be repeated to specify fallback fonts. This is useful in multilingual environments: the primary font can handle English and symbols, while later fonts cover Chinese, Japanese, or other characters. When you encounter display details such as emoji, bold, italic, or ligatures, look up the corresponding options in the Option Reference.

Shell Integration: Especially Important for SSH Users

Ghostty supports automatic Shell integration injection for bash, elvish, fish, nushell, and zsh. When enabled, several interactions become more natural:

New terminals can open in the previous terminal’s working directory.
Complex prompts can redraw correctly after resize instead of reflowing badly.
You can jump between command outputs using prompt markers.
Cursor behavior at the prompt can better match editing habits.

If you do not want automatic injection, disable it in the configuration:

`1`	`shell-integration = none`

SSH deserves extra attention. Ghostty uses xterm-ghostty as TERM, but many remote hosts do not yet have the corresponding terminfo. The docs provide two Shell integration features, ssh-env and ssh-terminfo, which are disabled by default and can be enabled as needed:

`1`	`shell-integration-features = ssh-env,ssh-terminfo`

If you often connect to old servers, containers, bastion hosts, or tightly managed production environments, read the official Terminfo and Shell Integration docs before enabling these features. Terminal capability negotiation looks minor, but when it goes wrong, the symptoms can be strange colors, broken shortcuts, or garbled full-screen programs.

My Suggested Onboarding Order

If you only want to judge whether Ghostty fits you, try this sequence:

Install it and use it for a day without writing any configuration.
Adjust only font-family, font-size, and theme.
Use ghostty +list-keybinds --default to inspect default shortcuts instead of importing someone else’s shortcut table first.
If you use SSH often, check remote host terminfo compatibility early.
Finally, tune splits, windows, transparency, title bar, background image, and other visual or workflow preferences.

Ghostty’s docs are engineering-oriented. They are better read as a configuration reference manual than as a marketing page. For most users, the real evaluation criteria are simple: does the default experience already feel comfortable, and are your daily editor, Shell, SSH, tmux, or Zellij workflows stable? If those pieces work well, Ghostty deserves a place on your long-term terminal shortlist.

References

How to Change the VS Code Display Language: Chinese, English, and More

Fri, 08 May 2026 13:18:57 +0800

VS Code supports many display languages. The usual approach is to install the matching language pack, then choose the display language from the Command Palette. If you want to pin VS Code to a specific language, you can also edit the locale value in argv.json.

This method works not only for Simplified Chinese, but also for English, Traditional Chinese, Japanese, Korean, French, German, Spanish, and other languages.

Install the Language Pack

If you want to switch to a non-English interface, you usually need to install a language pack first.

Open the Extensions panel in the left sidebar, or press Ctrl+Shift+X.
Search for the target language, such as Chinese, Japanese, Korean, or French.
Select the matching language pack and click Install.
Restart VS Code when prompted.

For Simplified Chinese, the common language pack is Chinese (Simplified). For Traditional Chinese, use Chinese (Traditional).

Change the Language from the Command Palette

This is the recommended method for most users.

Open the Command Palette with Ctrl+Shift+P.
Type Configure Display Language.
Select the Configure Display Language command.
Choose the language you want from the list.
Restart VS Code when prompted.

After restarting, menus, settings pages, and common prompts will use the selected language. If the target language is not listed, install its language pack from the Extensions panel first.

Set the Language Manually in argv.json

If switching from the Command Palette does not work, or if you want to explicitly lock VS Code to a language, you can edit the runtime arguments file directly.

Open the Command Palette with Ctrl+Shift+P.
Type and select Preferences: Configure Runtime Arguments.
Find or add the locale setting.
Change its value to the target language code.
Save the file and restart VS Code.

For example, switch to English:

1
2
3

{
  "locale": "en"
}

Switch to Simplified Chinese:

1
2
3

{
  "locale": "zh-cn"
}

Switch to Japanese:

1
2
3

{
  "locale": "ja"
}

argv.json is a JSON file, so pay attention to commas and quotation marks. If the configuration is invalid, VS Code may not read the language setting correctly.

Common Display Language Codes

Display language	locale
English (US)	`en`
Simplified Chinese	`zh-cn`
Traditional Chinese	`zh-tw`
French	`fr`
German	`de`
Italian	`it`
Spanish	`es`
Japanese	`ja`
Korean	`ko`
Russian	`ru`
Portuguese (Brazil)	`pt-br`
Turkish	`tr`
Bulgarian	`bg`
Hungarian	`hu`

What to Do If the Language Does Not Change

Check the following items in order:

Confirm that the target language pack is installed.
Confirm that locale uses the correct language code. For example, Simplified Chinese is zh-cn, not zh-CN.
Fully close and reopen VS Code after changing the language.
If you edited argv.json manually, check that the JSON syntax is valid.
If the configuration is messy, remove the locale entry and choose the language again through Configure Display Language.

In most cases, Configure Display Language is the simplest option. Edit argv.json only when you need to force a specific language or the Command Palette switch does not take effect.

References

VScode: Change the VS Code display language to Simplified Chinese and switch the VS Code display language

opencode, Claude Code, and Codex: What's the Difference? A Guide to Open Source AI Coding Tools

Fri, 08 May 2026 08:33:37 +0800

opencode is an open source AI Coding Agent from anomalyco. Its positioning is straightforward: give developers a programmable, extensible coding assistant in the terminal that can connect to multiple model providers.

If you compare it with Claude Code and Codex, all three solve the same broad problem: bringing AI into real codebases so it can understand context, edit files, run commands, and execute tests. But their product directions are different.

opencode emphasizes open source, multi-model support, and a terminal TUI. Claude Code emphasizes Anthropic’s model ecosystem and local engineering collaboration. Codex is OpenAI’s AI coding agent, available through the terminal, IDEs, the Codex app, and cloud tasks.

Who opencode Is For

opencode is a better fit for these kinds of developers:

People who want to complete code changes, project analysis, and engineering tasks in the terminal.
People who do not want their AI Coding Agent tied to a single model provider.
People who prefer open source tools and want to audit, extend, or build on top of them.
People already comfortable with Neovim, TUIs, and command-line workflows.
People who want to eventually drive the same coding agent remotely through a desktop app, mobile app, or other clients.

Its point is not to create another chat window, but to put AI coding capability inside the terminal and project directories developers already use.

Installation

The official README provides several installation methods.

# Direct install
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS and Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# Other methods
mise use -g opencode
nix run nixpkgs#opencode

The official README also recommends removing versions older than 0.1.x before installing to avoid problems caused by older remnants.

The installation script chooses the installation directory by priority:

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

If you need to specify a path, use:

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

The Desktop App Is Still Beta

In addition to the command-line tool, opencode also provides a desktop app, currently marked as Beta. It can be downloaded from GitHub Releases or opencode.ai/download.

The desktop app covers these platforms:

Platform	File
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`, `.rpm`, or `.AppImage`

macOS and Windows users can also install the desktop app through package managers.

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

Two Built-In Agent Modes

opencode includes two built-in Agents, switchable with the Tab key.

build is the default mode. It has full development permissions and is suitable for editing code directly, running commands, and moving engineering tasks forward.

plan is read-only mode. It is better for analyzing unfamiliar codebases, understanding project structure, and planning changes. It denies file edits by default and asks before running bash commands.

opencode also includes a general subagent for complex searches and multi-step tasks. Users can invoke it by typing @general in a message.

This design is practical: use plan to understand the project before acting, then switch to build when code needs to change. For large repositories, separating read and write permissions helps reduce mistakes.

What Is Codex?

Codex is OpenAI’s AI coding agent for helping developers write code, review code, fix bugs, and ship engineering tasks.

Unlike a simple code completion tool, Codex is closer to an Agent that can operate on a codebase. It can pair with you in local tools, and it can also take delegated tasks in the cloud. OpenAI’s official materials describe Codex as available through multiple surfaces, including CLI, IDEs, the Codex app, and ChatGPT/Codex cloud workflows.

For developers, Codex has several important traits:

It can read codebases, edit files, run commands, and execute tests.
It supports multiple interfaces, including terminal, IDE, app, and cloud.
It fits bug fixing, feature work, refactoring, migrations, code review, and test generation.
It is more closely tied to OpenAI accounts, models, and the Codex product ecosystem.
Cloud tasks are useful for running multiple well-scoped engineering tasks in parallel.

If opencode is more like an open terminal agent framework, Codex is more like a full AI coding workbench from OpenAI: local pairing, cloud delegation, and longer engineering workflows for teams.

Core Differences

opencode, Claude Code, and Codex are all AI coding tools, but the choice becomes clearer if you look at these dimensions.

Tool	Core Positioning	Main Advantages	Best Fit
`opencode`	Open source AI Coding Agent	Open source, multi-model, TUI, client/server architecture	Developers who want an open toolchain, replaceable models, and a terminal-first workflow
`Claude Code`	Anthropic’s command-line coding tool	Claude model experience, code understanding, long context, engineering task collaboration	Developers already using the Claude/Anthropic ecosystem who want to work on local code tasks
`Codex`	OpenAI’s AI coding agent	CLI, IDE, Codex app, cloud tasks, multi-Agent workflows	Teams already using ChatGPT/OpenAI who want both local pairing and cloud delegation

In short, opencode is about openness and replaceability, Claude Code is about the Claude ecosystem and local engineering agents, and Codex is about the OpenAI ecosystem and multi-surface collaboration.

How It Differs From Claude Code

opencode’s official FAQ directly compares it with Claude Code. The two are similar in capability, but the main differences are these.

First, opencode is a 100% open source project, hosted on GitHub and released under the MIT license.

Second, opencode is not tied to a single model provider. It recommends models provided through OpenCode Zen, but it can also work with Claude, OpenAI, Google, or local models. For developers, this means that when model cost, capability, or availability changes, you are not locked into one platform.

Third, opencode includes optional LSP support. For code completion, navigation, diagnostics, and project understanding, LSP is a very important foundation.

Fourth, opencode emphasizes TUI. It is built by Neovim users and the creators of terminal.shop, so the product focus is clearly on the terminal experience.

Fifth, opencode uses a client/server architecture. That means opencode can run on your computer while being controlled in the future by a TUI, desktop app, mobile app, or other clients. The TUI is only one possible frontend.

When to Choose opencode, Claude Code, or Codex

If you already use Claude Code or Codex, opencode does not have to replace them immediately. A better way to think about it is that opencode provides an open, model-replaceable, terminal-first option.

Consider opencode first when:

You want your AI coding tool to be as open source as possible.
You do not want your workflow tied to one model provider.
You want to test Claude, OpenAI, Google, or local models with the same tool.
You like TUI workflows and do not want a desktop or web app to interrupt your main workflow.
You care about the remote-control potential of a client/server architecture.

Consider Claude Code first when:

You mainly use Claude models.
You care about long context, code understanding, and complex engineering task collaboration.
You want to keep moving edits, tests, and refactors forward in a local repository.
You trust Anthropic’s default Claude Code product experience.

Consider Codex first when:

You already use ChatGPT or the OpenAI account ecosystem.
You want one coding agent across terminal, IDE, desktop app, and cloud tasks.
You want to delegate well-scoped bug fixes, feature work, migrations, or test generation to the cloud in parallel.
You need code review, background tasks, team collaboration, and multi-Agent workflows.

If you care more about an official end-to-end experience, default model configuration, enterprise management, and ready-made integrations, Claude Code or Codex may be easier. If you care more about control, openness, and being provider-agnostic, opencode is worth watching.

Things to Note

opencode, Claude Code, and Codex are all moving quickly. GitHub releases, installation commands, desktop app file names, model availability, and plan access can all change. Before installing or choosing a tool, check the official README, documentation, and release pages.

Also, opencode’s desktop app is still marked as Beta, so it should not be treated as the default stable production tool. For everyday engineering tasks, the terminal version is still the main entry point.

From a tooling trend perspective, opencode represents the open-toolchain direction for AI Coding Agents: replaceable models, replaceable clients, and an open core agent capability. Codex and Claude Code are closer to model companies turning coding agents into complete product surfaces. For developers, both directions will likely coexist for a long time.

References

opencode GitHub: https://github.com/anomalyco/opencode
opencode official site: https://opencode.ai
opencode docs: https://opencode.ai/docs
opencode Releases: https://github.com/anomalyco/opencode/releases
OpenAI Codex: https://openai.com/codex/
Using Codex with your ChatGPT plan: https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started: https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

uv Installation Guide: Choosing Between macOS, Linux, Windows, pipx, Homebrew, and WinGet

Thu, 07 May 2026 23:23:58 +0800

uv is a Python toolchain manager from Astral. It can manage Python versions, virtual environments, dependencies, scripts, projects, and tools. There are many ways to install it. The official documentation provides standalone installer scripts and also supports PyPI, Homebrew, WinGet, Scoop, Docker, GitHub Releases, and Cargo.

If you just want a quick installation, use the official standalone installer first. If you prefer your system package manager to maintain versions, use Homebrew, WinGet, or Scoop. If you already like installing Python tools in isolated environments, use pipx.

Quick Choice

Scenario	Recommended method	Command
Quick install on macOS / Linux	Official standalone installer	`curl -LsSf https://astral.sh/uv/install.sh \| sh`
macOS / Linux without curl	Official script + wget	`wget -qO- https://astral.sh/uv/install.sh \| sh`
Quick install on Windows	PowerShell installer	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`
Isolated Python tool install	pipx	`pipx install uv`
Temporary or traditional Python install	pip	`pip install uv`
macOS package management	Homebrew	`brew install uv`
macOS MacPorts users	MacPorts	`sudo port install uv`
Windows package management	WinGet	`winget install --id=astral-sh.uv -e`
Windows Scoop users	Scoop	`scoop install main/uv`
Rust users	Cargo	`cargo install --locked uv`

The generally recommended options are:

macOS / Linux: official standalone installer;
Windows: official PowerShell installer or WinGet;
If you already manage Python CLI tools with pipx: pipx install uv.

macOS and Linux: Official Installer

The most direct official method is to download the script with curl and run it with sh:

`1`	`curl -LsSf https://astral.sh/uv/install.sh \| sh`

If the system does not have curl, use wget:

`1`	`wget -qO- https://astral.sh/uv/install.sh \| sh`

To install a specific version, put the version number in the URL. For example, the official example uses 0.11.11:

`1`	`curl -LsSf https://astral.sh/uv/0.11.11/install.sh \| sh`

This method fits most personal development environments. It is simple, cross-platform, and works best with uv’s official update mechanism.

The installer puts binaries such as uv and uvx under the user directory, and may modify the shell profile so the commands can be used directly in the terminal. If you do not want the installer to modify PATH, check the official installer options, such as setting UV_NO_MODIFY_PATH=1.

Windows: PowerShell Installer

The official Windows method is to run the installer script with PowerShell:

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`

To install a specific version, also put the version number in the URL:

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/0.11.11/install.ps1 \| iex"`

ExecutionPolicy ByPass allows PowerShell to fetch and run the installer script from the internet. As a safer habit, you can inspect the script before running it:

`1`	`powershell -c "irm https://astral.sh/uv/install.ps1 \| more"`

If you prefer Windows package managers, WinGet or Scoop may be a better first choice.

Installing with pipx

The official documentation notes that uv is published to PyPI. If you install from PyPI, it is recommended to put it in an isolated environment, for example with pipx:

`1`	`pipx install uv`

This is suitable if you already use pipx as your Python CLI tool manager. It avoids mixing uv with your current project environment.

If you do not have pipx, you can also use pip directly:

`1`	`pip install uv`

Note that uv provides prebuilt wheels on many platforms. If a platform does not have a matching wheel, it will build from source, which requires a Rust toolchain.

My suggestion: on a personal machine, pipx install uv is cleaner than pip install uv; inside a project environment, do not install uv as a project dependency.

Homebrew, MacPorts, WinGet, and Scoop

If you prefer system package managers, uv also supports common channels.

Use Homebrew on macOS:

`1`	`brew install uv`

MacPorts users can use:

`1`	`sudo port install uv`

Use WinGet on Windows:

`1`	`winget install --id=astral-sh.uv -e`

Scoop users can use:

`1`	`scoop install main/uv`

The benefit of these methods is that version maintenance is delegated to the system package manager. The downside is that update timing depends on the corresponding package source, not the uv official installer.

Docker, GitHub Releases, and Cargo

uv also provides Docker images on GitHub Container Registry:

`1`	`ghcr.io/astral-sh/uv`

This is suitable for CI, Dockerfiles, image builds, and temporary runtime environments. In real usage, read the official Docker integration documentation as well.

If you want to download binaries manually, use GitHub Releases. Each release page usually includes binaries for supported platforms and explains how to invoke the standalone installer with a GitHub URL.

Rust users can also install from crates.io:

`1`	`cargo install --locked uv`

This builds from source and requires a compatible Rust toolchain. Unless you specifically want to install from the Rust ecosystem, ordinary users do not need to choose Cargo first.

Upgrading uv

If uv was installed with the official standalone installer, use the self-update command:

`1`	`uv self update`

The official documentation notes that updating uv reruns the installer and may modify the shell profile. If you do not want the update to modify PATH, set:

`1`	`UV_NO_MODIFY_PATH=1`

If you installed uv another way, use the corresponding package manager. For example, if you installed it with pip, use:

`1`	`pip install --upgrade uv`

Homebrew, WinGet, Scoop, and MacPorts should also use their own upgrade commands.

Enabling Shell Completion

uv supports shell completion. The official documentation recommends checking your current shell first:

`1`	`echo $SHELL`

Bash:

`1`	`echo 'eval "$(uv generate-shell-completion bash)"' >> ~/.bashrc`

Zsh:

`1`	`echo 'eval "$(uv generate-shell-completion zsh)"' >> ~/.zshrc`

fish:

`1`	`echo 'uv generate-shell-completion fish \| source' > ~/.config/fish/completions/uv.fish`

PowerShell:

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uv generate-shell-completion powershell) | Out-String | Invoke-Expression'

If you often use uvx, you can enable completion for uvx separately.

Bash:

`1`	`echo 'eval "$(uvx --generate-shell-completion bash)"' >> ~/.bashrc`

Zsh:

`1`	`echo 'eval "$(uvx --generate-shell-completion zsh)"' >> ~/.zshrc`

fish:

`1`	`echo 'uvx --generate-shell-completion fish \| source' > ~/.config/fish/completions/uvx.fish`

PowerShell:

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uvx --generate-shell-completion powershell) | Out-String | Invoke-Expression'

After configuration, restart the shell or reload the corresponding configuration file.

Uninstalling uv

To uninstall uv, you can first clean the cache and uv-managed data:

1
2
3

uv cache clean
rm -r "$(uv python dir)"
rm -r "$(uv tool dir)"

Then delete the binaries.

macOS / Linux:

`1`	`rm ~/.local/bin/uv ~/.local/bin/uvx`

Windows:

1
2
3

rm $HOME\.local\bin\uv.exe
rm $HOME\.local\bin\uvx.exe
rm $HOME\.local\bin\uvw.exe

The official documentation also notes that before 0.5.0, uv installed into ~/.cargo/bin. If you upgraded from an earlier version, old binaries may still be there and need to be removed manually.

What to Do After Installation

After installation, check the version first:

`1`	`uv --version`

Then start with a few common tasks:

uv python install
uv venv
uv pip install requests
uvx ruff --version

For a new project, continue with:

uv init: initialize a project;
uv add: add dependencies;
uv sync: sync the environment;
uv run: run commands inside the project environment;
uvx: run Python CLI tools temporarily.

My Recommendation

On a personal development machine, prefer the official standalone installer because it follows the uv official documentation most closely and supports uv self update.

Windows users who do not want to run a remote script can use WinGet or Scoop. macOS users who prefer managing all tools with Homebrew can directly use brew install uv.

If you already manage Python CLI tools with pipx, use pipx install uv. But I do not recommend installing uv with pip install uv inside a specific project virtual environment, because that tends to mix the toolchain with project dependencies.

For CI or container builds, start with Docker and GitHub Releases, and pin versions according to your image build process.

uv installation documentation: https://docs.astral.sh/uv/getting-started/installation/
uv First steps: https://docs.astral.sh/uv/getting-started/first-steps/
uv Docker integration: https://docs.astral.sh/uv/guides/integration/docker/
uv GitHub Releases: https://github.com/astral-sh/uv/releases

Awesome Codex Skills: A Community Catalog for Extending Codex CLI

Thu, 07 May 2026 20:19:15 +0800

ComposioHQ’s awesome-codex-skills is a community catalog for Codex CLI skills. Its value is not another pile of prompt templates, but a way to package repeatable workflows into installable, reusable, and maintainable Skills.

If you already use Codex as part of daily development, this kind of repository is immediately useful: rules, commands, reference materials, and operating steps that you used to explain again and again can be written down once, then reused whenever the matching Skill is invoked.

What This Repository Solves

Codex Skills can be understood as specialized work modes for Codex CLI. A normal prompt is good for one temporary instruction; a Skill is better for something you want to reuse over time.

For example, you may often need to:

generate commit messages in a fixed format;
look up a specific family of API documentation;
run project-specific test and deployment commands;
rewrite articles, translate docs, or organize notes according to team rules;
call external tools for repetitive development tasks.

Typing these instructions every time quickly becomes overhead. A Skill puts the rules into a standalone directory. The core is usually a SKILL.md file, sometimes accompanied by scripts, templates, reference documents, or assets. When Codex is triggered, it reads the instructions and follows the workflow described there.

How It Differs From a Prompt

A prompt is more like a one-off instruction: “do this task this way.” A Skill is closer to a small operating manual: “whenever this class of task appears, work in this way.”

Its main advantages are:

Reusable: common workflows no longer need copy-and-paste setup.
Reviewable: skill files are usually local Markdown files that can be opened, edited, and versioned.
Extensible: complex skills can include scripts, templates, and references, not just natural language instructions.

That is why catalogs like awesome-codex-skills are useful: they help you discover existing skills, then adapt them to your own workflow.

Installation and Use

The repository provides an installation script and also supports manual installation. A typical flow is:

1
2
3

git clone https://github.com/ComposioHQ/awesome-codex-skills.git
cd awesome-codex-skills
python install.py

If you only want to try a few skills, read the SKILL.md in each skill directory first. Check what it reads, what scripts it may run, what files it may edit, and whether the defaults fit your local environment.

After installation, Codex can match skills when the task calls for them, or you can name a skill explicitly. For long-term use, the most practical approach is often to install a community skill first, then rewrite the instructions around your own project conventions.

Which Skills Are Worth Watching

The most valuable skills are not necessarily the ones with the flashiest names. They are the ones that reliably remove repeated work.

I would first look at:

Development workflow skills: review, testing, commits, releases, dependency checks.
Documentation skills: rewriting, translation, summarization, structured organization.
Tool integration skills: connecting Codex to external services, APIs, and CLI tools.
Project convention skills: encoding team rules, directory structure, naming conventions, and deployment steps.

If a skill merely wraps a single sentence prompt, it has limited value. If it can connect research, judgment, execution, verification, and output into a stable workflow, it is worth keeping.

What to Watch Out For

Community skills are convenient, but they should not be treated as black boxes. This is especially true for Skills that include scripts. Before installing one, check:

what SKILL.md asks Codex to do;
whether it includes scripts that access the network, read or write files, or call external services;
whether the default paths, commands, and permissions fit your machine.

A Skill expands what Codex can do. Written well, it makes Codex feel more like a teammate who knows your project. Written carelessly, it can bring unsuitable rules into your workflow. The best pattern is not to install many skills, but to keep a small set, tune them carefully, and maintain them over time.

My Take

awesome-codex-skills is worth bookmarking, especially if you already use Codex CLI for real development, documentation, or automation work. It is not an official capability by itself; it is a community entry point for finding and adapting reusable workflows.

For heavy users, the point of Codex Skills is not simply helping AI remember more. It is helping AI make fewer detours on repeated tasks. Writing rules as Skills turns temporary instructions into reusable working infrastructure.

Warp Open Source: From Terminal to Agentic Development Environment

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp is the open-source client repository for Warp. Warp now describes itself as an “agentic development environment, born out of the terminal”: it starts from the terminal, but brings AI coding agents, codebase indexing, task management, and development workflows into one environment.

This is not an ordinary open-source terminal emulator repository. It is closer to an answer to a larger question: as agents such as Claude Code, Codex, and Gemini CLI become common, should the terminal itself become a development environment for scheduling, observing, and managing agents?

Warp’s answer is yes.

Current State of the Repository

As of May 7, 2026, warpdotdev/warp is a public repository. GitHub shows roughly 56k stars and 4.1k forks. The README says the Warp client code is now open source and welcomes community contributions.

The main language is Rust. GitHub’s language breakdown shows Rust at over 98%, which matches Warp’s positioning: it is not a web wrapper, but a cross-platform native development tool.

Several README details matter:

Warp is an agentic development environment, born out of the terminal.
It can use its built-in coding agent and can also connect to external CLI agents such as Claude Code, Codex, and Gemini CLI.
OpenAI is the founding sponsor of the newly open-sourced Warp repository.
The agentic management workflows in the repository are powered by GPT models.
Warp UI framework crates use the MIT license, while the rest of the code uses AGPL v3.

This shows that Warp’s open source move is not merely publishing a terminal. It is operating the project as an experiment ground for agent workflows.

Warp Is More Than a Terminal

Traditional terminals mainly do three things:

start a shell;
run commands;
display output.

Warp’s earlier differentiation was making the terminal feel more modern: command blocks, completion, history, collaboration, UI-style interactions, and cross-platform polish. Now the focus has moved further toward organizing development around AI agents.

From the README, Warp no longer only emphasizes “a better terminal.” It emphasizes:

built-in coding agents;
external CLI agent support;
issue triage;
spec writing;
PR review;
contributor coordination;
observable agent sessions.

In other words, Warp wants to turn the terminal from “where you type commands” into “where you work with multiple agents.”

Oz and Open-Source Project Management

The README mentions Oz several times.

Warp’s contribution overview shows thousands of Oz agents working on issue triage, specs, implementation, and PR review. This is interesting because it extends AI agents from “helping one person write code” to “helping manage open-source collaboration.”

The hardest part of many open-source projects is not writing code, but maintenance:

too many issues, not enough classification;
bugs and feature requests mixed together;
new contributors unsure which tasks are approachable;
PR review pressure;
maintainers struggling to follow every community thread.

Warp’s idea is to let agents take on part of the project management and collaboration work first. The README also mentions Oz for OSS, a maintainer-facing program for bringing similar agentic open-source management workflows to other repositories.

This suggests that Warp’s ambition is not only the terminal product itself, but also a new model of open-source maintenance in the AI era.

Repository Structure and Tech Stack

From the repository structure, Warp is a large Rust project.

The root contains:

app/: main application code.
crates/: core Rust crates.
assets/: resource files.
command-signatures-v2/: command signature related content.
docker/, script/, resources/, specs/, and other engineering directories.
.claude/, .warp/, .agents/skills, and other agent-related configuration.

WARP.md gives more engineering detail. It describes Warp as a Rust-based terminal emulator using an in-house UI framework called WarpUI.

The major modules can be roughly understood as:

app/: terminal emulation, shell management, AI integration, Drive, authentication, settings, workspace, and sessions.
crates/warp_core/: core utilities and platform abstraction.
crates/editor/: text editing functionality.
crates/warpui/ and crates/warpui_core/: the in-house UI framework.
crates/ipc/: inter-process communication.
crates/graphql/: GraphQL client and schema.

WARP.md also mentions architectural features such as:

an Entity-Handle system;
a modular workspace structure;
macOS, Windows, Linux, and WASM targets;
AI integration, including Agent Mode, context awareness, and codebase indexing;
Warp Drive cloud sync.

This complexity is closer to a full IDE than a lightweight traditional terminal.

Local Build Commands

The README gives a concise local build flow:

1
2
3

./script/bootstrap
./script/run
./script/presubmit

Where:

./script/bootstrap performs platform-specific initialization.
./script/run builds and runs Warp.
./script/presubmit runs formatting, clippy, tests, and other pre-submit checks.

WARP.md also lists more detailed commands:

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

If you want to contribute to Warp, ./script/presubmit is effectively required.

Contribution Flow

Warp’s contribution flow is not simply “open a PR.”

The README describes a lightweight process from issue to PR:

Search existing issues first.
If there is no duplicate, file a bug or feature request.
Maintainers review the issue and may add readiness labels.
ready-to-spec means the design can be expanded into a spec.
ready-to-implement means the design is clear enough to start an implementation PR.
Contributors can pick up labeled issues.

This process fits a large open-source project. It separates ideas, design, and implementation, reducing the risk that contributors spend time building in the wrong direction.

It also fits AI agents well. An agent can organize issues, draft specs, add tests, and then move into implementation. Warp itself uses this pattern to demonstrate agentic project management.

License: MIT + AGPL v3

Warp uses a dual license structure.

The README says:

the Warp UI framework, namely the warpui_core and warpui crates, uses the MIT license;
the rest of the repository uses AGPL v3.

This matters. AGPL v3 has stronger open-source requirements for network services and distribution. If you are learning, researching, or contributing, it is usually straightforward. But if you want to use Warp code in a commercial product or closed-source derivative, you need to read the license carefully and consult legal advice if necessary.

In short, Warp is open source, but not “take it and close-source it freely” open source.

Why It Is Worth Watching

First, Warp brings the terminal, agents, and project management together.

Many AI coding tools are still CLI tools or editor plugins. Warp starts from the terminal entry point and tries to unify agent tasks, code execution, command output, PR workflows, and team collaboration.

Second, Warp’s open-source approach is a good place to observe agent workflows.

It does not only publish code. It also exposes contribution overviews, agent sessions, issue triage, and spec workflows. For anyone studying how AI can participate in open-source collaboration, the repository itself is a sample.

Third, Warp is a complex Rust desktop application.

If you want to study Rust GUI, terminal emulation, cross-platform apps, GraphQL clients, cloud sync, and AI integration, the repository has a lot to read. But it is not a small project, so new contributors should read the docs and issue process first.

Fourth, Warp supports both a built-in agent and a “bring your own CLI agent” approach.

This is realistic. Developers will not use only one agent. Claude Code, Codex, Gemini CLI, OpenCode, OpenClaw, and similar tools are likely to coexist. If Warp can become a workbench for them, it becomes more valuable than a single-purpose terminal.

Who Should Care

If you are a normal terminal user, Warp matters because the terminal may be changing from a command-line tool into an AI workbench.

If you are a heavy AI coding agent user, Warp is worth watching because it tries to manage multiple agents rather than act as another chat entry point.

If you maintain open-source projects, the Oz for OSS direction is worth attention. It explores agent-based issue triage, PR review, community collaboration, and contributor onboarding.

If you are a Rust developer, Warp is a real large-scale desktop application worth studying for UI organization, terminal internals, cloud sync, AI integration, and cross-platform code.

If you only want a terminal that can replace your current one immediately, it is better to download the stable release first, then decide whether to study the source. Building from source is more suitable for contributors and deep users.

Short Take

The point of Warp going open source is not merely “a modern terminal became open source.”

More precisely, Warp is trying to upgrade the terminal into an agentic development environment: the terminal connects the shell, codebase, command execution, agents, issues, PRs, and collaboration flow.

As AI coding agents keep growing, the entry point of the development environment may change. In the past, the IDE dominated the developer experience while the terminal ran commands. Now the terminal may become the center of agent collaboration. The Warp repository is exploring that possibility.

GitHub repository: https://github.com/warpdotdev/warp
Warp website: https://www.warp.dev
Warp documentation: https://docs.warp.dev
Warp build overview: https://build.warp.dev
WARP.md: https://github.com/warpdotdev/warp/blob/master/WARP.md
CONTRIBUTING.md: https://github.com/warpdotdev/warp/blob/master/CONTRIBUTING.md

Getting Started with Compiling UEFI Programs: From uefi-simple to Your First .EFI

Thu, 30 Apr 2026 19:53:08 +0800

Compiling your first UEFI program is not exactly effortless. Environment setup can take time, linker errors are common, and a .EFI program does not have the same direct edit-and-run experience as an ordinary desktop application.

This article organizes the topic from a beginner’s perspective: if you only want to compile your first UEFI program, where should you start, which concepts matter first, and which pitfalls are most likely to appear?

What Is a UEFI Program?

A UEFI program is usually a .EFI file.

It is not an ordinary .exe that you double-click in Windows. It is a PE/COFF executable that runs inside the UEFI firmware environment. Common use cases include:

Boot managers
Hardware initialization tools
Firmware update tools
Pre-boot diagnostic tools
Custom boot flows

Many functions you see early in the system boot process may be related to UEFI applications, drivers, or firmware services.

For beginners, there is no need to understand full firmware development immediately. The first goal is simple: compile a .EFI file that can be loaded by a UEFI Shell or emulator.

Why Not Start with EDK II?

Real UEFI development often involves EDK II.

EDK II is complete and closer to real firmware engineering, but it is not very friendly for beginners:

The project structure is complex
The build system has a learning curve
Environment variables and toolchain setup involve many details
Compiler errors are not always easy to understand
It is easy to get stuck on the environment before writing any code

If the goal is simply to get a minimal UEFI program running, a lightweight example is a better starting point.

pbatard/uefi-simple is one such project. Its goal is straightforward: provide a simple UEFI Hello World example so you can compile a .EFI file first.

What Is `uefi-simple` Good For?

uefi-simple is a good first stepping stone for UEFI beginners.

It solves three practical problems:

It gives you a minimal compilable UEFI application structure
It avoids the complexity of large firmware projects at the beginning
It lets you verify that compiling, linking, and running all work

The project supports multiple build methods, including Visual Studio 2022 and MinGW/gcc. It can also be tested with QEMU and OVMF.

In other words, you do not have to repeatedly reboot a real machine for early experiments. Running the program in an emulator first is much safer.

What to Prepare Before Starting

You need at least a few categories of tools.

The first category is the compiler toolchain.

On Windows, you can start with:

Visual Studio 2022
Or MinGW/gcc

The second category is a UEFI runtime environment.

There are two common options:

Run the .EFI file in a real machine’s UEFI Shell
Test it in a virtual environment with QEMU + OVMF

The third category is an example project.

Beginners should not start by writing build scripts from an empty directory. Using a minimal example such as uefi-simple helps avoid many build-system problems.

Basic Workflow

A minimal UEFI program workflow can be understood like this.

First, get the example project.

`1`	`git clone https://github.com/pbatard/uefi-simple.git`

Second, choose a build toolchain.

If you use Visual Studio, build with the Visual Studio solution in the project.
If you use MinGW/gcc, follow the Makefile or instructions provided by the project.

Third, generate the .EFI file.

The key point here is to confirm the target architecture. A common PC is usually x86_64, meaning a 64-bit UEFI environment.

Fourth, put the .EFI file somewhere the UEFI Shell can access.

On a real machine, this usually means preparing a FAT32 partition or USB drive.
With QEMU, you can mount a directory or disk image.

Fifth, run it in the UEFI Shell.

The result is usually a minimal output, such as a Hello World-style message.

Where Beginners Usually Get Stuck

The hardest part of compiling a UEFI program is usually not the C language itself, but the environment and linking process.

Common issues include:

Wrong compiler architecture
Wrong target format
Incomplete linker parameters
Missing UEFI entry point
Generating an ordinary executable instead of a UEFI-loadable .EFI
QEMU or OVMF not configured correctly
Secure Boot on a real machine blocking an unsigned program

Linker errors are especially easy to misread as code problems.
In many cases, the real issue is the entry function, subsystem, target architecture, or linker script.

So in the first stage, do not rush into complex logic. Make sure the original example can compile and run, then change the output little by little.

Why Use QEMU + OVMF for Testing?

Testing UEFI programs on a real machine is possible, but it is not convenient at the beginner stage.

You may have to repeat this cycle:

Compile
Copy to a USB drive
Reboot
Enter the UEFI Shell
Run the program
Record the error
Return to the system and modify the code

That loop is slow.

QEMU + OVMF lets you simulate a UEFI environment directly inside the operating system. You can verify whether a .EFI file loads more quickly, and it is less likely to affect your real boot entries.

Once the program basically works, testing it on a real machine is much more manageable.

What Should Beginners Modify First?

If you have already compiled your first .EFI with the example project, do not jump into complex features immediately.

A better order is:

Change the output text first to confirm that recompilation really takes effect.
Try reading simple information provided by UEFI.
Understand the entry function, output protocol, and basic services.
Then consider more complex features such as file systems, graphical output, or boot entry management.

This approach makes every step verifiable.
If you change too much at once, it becomes difficult to tell whether the issue is in the code, the build process, or the runtime environment.

How Is It Different from an Ordinary C Program?

Although UEFI programs can be written in C, their runtime environment is completely different from ordinary C programs.

An ordinary C program usually runs inside an operating system and can rely on the standard library, file system, process model, and system calls.

A UEFI program runs before the operating system boots. It relies on services provided by UEFI firmware. Many things you are used to in normal programs are not automatically available here.

When writing UEFI programs, you need to adapt to several differences:

The entry function is different
Output works differently
Available libraries are different
Memory and file access work differently
Debugging works differently

This is why starting from a minimal example is better than writing code as if it were a normal C program.

A Practical Learning Path

For beginners, a realistic path looks like this:

Step 1: Compile uefi-simple
Step 2: Run it with QEMU + OVMF
Step 3: Modify the Hello World output
Step 4: Understand how the UEFI Shell loads .EFI
Step 5: Learn the UEFI entry function and basic output protocol
Step 6: Then read EDK II or more complete UEFI development material

The point of this path is to build a working feedback loop first.

Once you can generate a .EFI from source and see output in a UEFI environment, you have already crossed the hardest first threshold.

References

Final Thought

The hard part of compiling your first UEFI program is usually not writing a bit of C code, but connecting the toolchain, link format, and runtime environment.

Do not rush into complex features.
Start with a minimal example such as uefi-simple, get a runnable .EFI first, and then gradually understand UEFI entry points, protocols, and build methods.

GoAccess Latest Build-from-Source Notes: From Source Install to Real-Time HTML Reports

Wed, 29 Apr 2026 00:08:00 +0800

This is organized for 2026-04-29.
At this point, the latest stable version listed in the official README is 1.10.2.

1. Install build dependencies first

1
2
3

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

2. Download the latest source package

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2

3. Configure build options

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib`

If you also want TLS support for real-time HTML reports:

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl`

4. Build and install

1
2

sudo make
sudo make install

5. Verify the version

1
2

goaccess --version
which goaccess

6. View reports directly in the terminal

For common Nginx or Apache combined logs:

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED`

If the log path is Apache:

`1`	`goaccess /var/log/apache2/access.log --log-format=COMBINED`

7. Generate a static HTML report

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html

You can also write it to the current directory:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o report.html

8. Generate a real-time HTML report

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

To change the port:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --port=7891

To bind only to localhost:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --addr=127.0.0.1

9. Follow logs continuously

`1`	`tail -f /var/log/nginx/access.log \| goaccess --log-format=COMBINED -`

From the beginning of the file and keep it live:

tail -f -n +0 /var/log/nginx/access.log | goaccess \
  --log-format=COMBINED \
  -o report.html \
  --real-time-html -

10. Look at only certain requests

For example, only requests containing firefox:

1
2

tail -f /var/log/nginx/access.log | grep -i --line-buffered 'firefox' | goaccess \
  --log-format=COMBINED -

For example, only 5xx and 3xx:

1
2
3

tail -f -n +0 /var/log/nginx/access.log | awk '$9~/3[0-9]{2}|5[0-9]{2}/' | goaccess \
  --log-format=COMBINED \
  -o out.html -

11. Analyze multiple logs together

`1`	`goaccess /var/log/nginx/access.log /var/log/nginx/access.log.1 --log-format=COMBINED`

Read compressed and uncompressed logs together:

`1`	`zcat --force /var/log/nginx/access.log* \| goaccess --log-format=COMBINED -`

12. Enable multithreading

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4

Increase chunk size:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4 \
  --chunk-size=8192

13. Incremental processing

Persist an older log first:

`1`	`goaccess /var/log/nginx/access.log.1 --log-format=COMBINED --persist`

Then append the current log:

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED --restore --persist`

Read only persisted data:

`1`	`goaccess --restore`

14. The set of commands I would run first

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2
sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl
sudo make
sudo make install

goaccess --version

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

That is basically it.
If your goal is clear, getting the latest source build installed and making --log-format=COMBINED plus --real-time-html work first is usually enough. After that, most changes are just about log paths, output files, and ports.

How to Choose an Embedded Development Environment in 2026: Keil, STM32CubeIDE, VS Code, and AI Collaboration

Wed, 22 Apr 2026 23:05:00 +0800

If you still work on microcontrollers or embedded systems, you will quickly run into a very practical question: in 2026, when AI-assisted coding has become increasingly common, what development environment actually makes sense?

On the surface, this looks like a comparison between several IDEs. But what it really asks is something else: do you want a tool that can simply get the project running, or a workflow that balances ecosystem compatibility, coding experience, and AI collaboration?

Seen from that angle, the answer is usually not to pick one out of Keil, STM32CubeIDE, VS Code, and CLion, but to recombine the parts each one does best.

First look at the main options and what each one really solves

In embedded development, the familiar names are still more or less the same:

Keil
STM32CubeIDE
VS Code
CLion

If you go back even further, people will still mention IAR. But for this discussion, what matters less is who has the oldest pedigree, and more who actually fits today’s development reality.

Keil: strong ecosystem, dependable entry point, but clearly outdated editing experience

Keil is still hard to avoid today, and the reason is simple: it is everywhere.

Whether you look at legacy company projects, online tutorials, shared examples, or older codebases, a huge amount of embedded work is still organized around Keil. Its build, download, and debug workflow remains mature, and if your main goal is to get code running on a board, it is still a very short path.

Its problems are just as obvious:

dated interface
average editing experience
not a natural home for AI-assisted coding

So Keil feels more like a project entry point and debugging foundation than an ideal editor for a 2026 coding experience.

STM32CubeIDE: friendly for STM32, but more of a learning and quick-start tool

If you mainly live inside the STM32 ecosystem, STM32CubeIDE is often the first environment you touch.

Its strengths are straightforward:

beginner-friendly onboarding
convenient peripheral configuration and project generation
a fairly complete debug chain

For students, beginners, and early project setup, that experience is direct and good enough.

But once you move into longer-running projects, heavier collaboration, and more customized workflows, its limitations become more visible. In commercial work or more complex team environments, it may not be the most comfortable primary environment.

So it fits better as a quick-start and STM32-centric all-in-one tool than as a long-term primary editor.

VS Code: not really an IDE, but increasingly strong in the AI era

Strictly speaking, VS Code is not a traditional IDE. More accurately, it is an extensible code editor.

That gives it a built-in dual nature.

Its weaknesses are:

it needs plugins and setup
it is not beginner-friendly enough
it cannot replace the full embedded IDE workflow out of the box

But its real strengths come from the same place:

strong extensibility
a much more modern coding experience
better highlighting, navigation, search, and refactoring
stronger momentum around AI tools and agent workflows

At this stage, many developers no longer just want something that lets them write code. They want to know whether AI collaboration can fit naturally into the same environment. From that perspective, the advantage of VS Code is hard to miss.

CLion: good experience, but not central enough in embedded practice

CLion often comes up because its C/C++ coding experience has long been considered solid.

But for many embedded developers, the question is not whether it is good. The question is whether it is worth switching to:

relatively fewer people use it in embedded workflows
it does not connect to existing embedded project ecosystems as directly as Keil
it may not offer a more practical AI-collaboration advantage than VS Code

So it feels more like a “theoretically good option” than the most natural center of a mainstream embedded workflow today.

A more practical answer: let Keil handle build and debugging, let VS Code handle coding

If you break these tools apart by role, a much more pragmatic conclusion appears:

use Keil to preserve existing project compatibility, build, flashing, and debugging
use VS Code for everyday coding, search, navigation, and AI collaboration

The value of this combination is that it does not try to force one tool to do everything. Instead, it puts each tool back in the role it is best at.

For many embedded projects, the Keil ecosystem is simply not optional. If that is true, then instead of forcing everything back into Keil, it makes more sense to treat it as the backend build-and-debug entry point, while handing the real editing experience to VS Code.

Why this combination makes more sense in the AI era

Today, the dividing line between environments is no longer just whether the editor feels smooth. It is whether AI can plug into the workflow naturally.

VS Code has several very practical strengths here:

more active support for AI plugins and agents
a code browsing experience better suited for AI reading and modifying projects
easier integration with modern plugin ecosystems

That means some of the most painful parts of embedded development can start to be offloaded to AI:

finding functions and call chains in an existing project
quickly generating initialization code
adding a simple UART print
explaining the structure of old projects
making small, localized edits in existing files

These tasks were never impossible before. They were just awkward. The meaning of VS Code is not only that it looks better. It is that it can more naturally become the workbench for AI collaboration.

The key patch: connect VS Code to Keil projects with plugins

Whether this workflow works in practice depends on one thing: can you actually connect VS Code to a Keil project?

A very practical class of plugins does exactly that by letting VS Code read Keil project structure and call Keil backend programs from inside the editor for tasks such as:

opening a project
building
downloading

That way, you do not have to constantly jump between two interfaces just to write code. You only return to Keil for the heavier debugging work such as stepping, breakpoints, and register inspection.

The real value of these plugins is not merely saving a few window switches. It is making the workflow continuous.

Do not overlook the basic C/C++ plugin setup

If you want to use VS Code as the main embedded editor, one basic but often ignored point is this: you must set up the core C/C++ plugin and project indexing properly.

Otherwise, you will run into a series of issues that seriously hurt the experience:

jump-to-definition does not work
false red underlines appear
completion quality is poor
header relationships become messy

Many people assume this means VS Code is not suitable for embedded work. In practice, it is often just that the indexing and plugin configuration are not connected correctly.

Once that layer is configured properly, VS Code can actually deliver on its strengths in reading large projects, searching symbols, and using AI to assist with targeted code changes.

Who this workflow fits best

I think this combination works especially well for the following groups.

1. People who already have a large amount of Keil-based projects

If your company projects, course materials, or historical code all revolve around Keil, there is no reason to throw that ecosystem away just for the sake of looking modern. Keep Keil, then add VS Code as the front end. That is usually the lowest-cost transition.

2. People who want AI to help with embedded coding

If you already like using AI to explain functions, generate boilerplate, or make local logic changes, VS Code will take on that role more naturally than traditional embedded IDEs.

3. People who want to balance learning materials and real projects

Many tutorials are still built around Keil, but your own workflow does not need to stay stuck in that era. Treat Keil as the compatibility layer and VS Code as the productivity layer, and the balance becomes much better.

Closing

By 2026, the key question in embedded development environments is no longer just which IDE has more features. It is which combination best fits how people actually work today.

If you only want to get started quickly, STM32CubeIDE still has its place. If you need to inherit a large amount of existing engineering reality, Keil is still unavoidable. But if you also want to bring in a modern editing experience and AI collaboration, the more practical answer is often this:

let Keil handle build and debugging, and let VS Code handle writing code.

It may not be the only answer, but it is very likely one of the least awkward answers available today.

How to Choose Among 8 Common Config File Formats: From INI, XML, JSON, YAML, TOML to Markdown

Wed, 22 Apr 2026 21:48:37 +0800

If you write code, manage servers, tweak game settings, or maintain toolchains, you almost certainly cannot avoid config files.

A lot of the time, what really blows up a program is not the algorithm or the framework, but one tiny line of configuration: one missing space, one extra comma, or one value written in a way the system did not expect. Looking at common config formats side by side naturally brings us back to a few core questions:

Which formats are friendlier for humans to write?
Which formats are friendlier for machines to parse?
In the AI Agent era, will the role of config files start to change?

This article is a concise attempt to organize that question.

01 A config file is basically a negotiation between humans and machines

There is one way to put it that I think is especially accurate: a config file is really a kind of behavioral contract between humans and programs.

Its value is obvious. You do not need to rewrite business logic or recompile anything. By changing just a few lines of text, you can alter website behavior, application logic, deployment behavior, or even game graphics and hidden options.

The problem is that this contract contains a built-in tension.

From the human side, what we want is:

something readable, writable, and structurally clear
preferably with comments so we and others can understand it later
as little repetition as possible, ideally with reuse and modularity
and a format that does not instantly explode because of one small mistake

But from the machine side, elegance is irrelevant. It mainly cares about two things:

parsing must be fast
the rules must be strict, types must be clear, and ambiguity should be minimized

That is why config formats are always pulled between “human-friendly” and “machine-friendly.” The better a format is for human reading, the more work machines often need to parse it. The more efficient it is for machines, the easier it often is for humans to make mistakes while editing it.

02 INI: simple and direct, but limited

Let’s start with INI.

Its strengths are extremely straightforward:

simple structure
sections plus key-value pairs that are easy to understand at a glance
support for comments
well suited for lightweight configuration, such as game tweaks or basic environment settings

If you have ever modified older game settings or manually adjusted tool parameters, you have probably seen it.

But INI also has obvious limitations. Its structure is too flat and it does not naturally represent deep nesting or arrays. On top of that, it usually lacks a strict type system, so many values are basically just strings and the program has to decide how to interpret them.

That makes INI feel like an old but convenient utility vehicle: great for light work, but easy to outgrow once the project gets more complex.

A very typical INI file might look like this:

[server]
host=127.0.0.1
port=8080

[feature]
enable_cache=true

03 XML: rigorous and stable, but tiring to write

The second major format is XML.

If you have maintained older Java projects or seen large configuration files full of paired closing tags, it should feel familiar.

The strengths of XML include:

clear hierarchical structure
support for comments
strict rules
strong validation when paired with a schema

That means machines can know field types, cardinality, and structural constraints before they even begin real parsing, which gives a strong sense of safety.

But its cost to humans is equally classic:

verbose tags
lots of visual noise
files that expand quickly
and one missing closing tag can sometimes break the whole page

That is why XML feels like a fully stamped formal contract. Machines like it, while humans often get tired maintaining it. Many newer projects no longer choose it first, but in older systems and strict-rule environments it still has not fully disappeared.

The same config written in XML might look like this:

<config>
  <server>
    <host>127.0.0.1</host>
    <port>8080</port>
  </server>
  <feature>
    <enable_cache>true</enable_cache>
  </feature>
</config>

04 JSON: dominant for data exchange, awkward for hand-edited config

In modern development, JSON is almost impossible to avoid.

The classic judgment about JSON is this: it is excellent as a data interchange format, but a little awkward as a human-maintained config format.

Its advantages include:

clear object and array structures
network-friendly transmission
mature parsers
strong fit for web APIs and frontend-backend communication

Especially next to XML, JSON looks much lighter. The same structure is often shorter in JSON, and much easier to send over networks.

But it has one major flaw: standard JSON does not support comments.

Its syntax is also strict:

keys must be in double quotes
the last item cannot have a trailing comma
one missing symbol can immediately break everything

So JSON is excellent for APIs and service-to-service exchange, but not always ideal for configuration that humans need to edit, explain, and revisit often.

For example:

{
  "server": {
    "host": "127.0.0.1",
    "port": 8080
  },
  "feature": {
    "enable_cache": true
  }
}

05 YAML: highly readable, but indentation and implicit typing can betray you

If you have worked with Docker, CI/CD, Kubernetes, or deployment automation, then you have almost certainly dealt with YAML.

Its biggest appeal is how clean it looks:

fewer braces and quotes
indentation expresses hierarchy
comments are supported
anchors can be used for reuse

So from a first-glance human perspective, YAML usually feels friendlier than JSON.

But the problem is also exactly there. It hides a lot of complexity, and in real use it often produces two classic failure modes:

indentation hell
implicit type conversion

Indentation issues are easy to understand: one extra or missing space can break the config. Worse still, implicit type conversion means some values that look like plain strings may be interpreted automatically as booleans or some other type.

That is why so many people praise how good YAML looks and at the same time suffer badly from it. It is genuinely good for human readability, but machines do not parse it effortlessly, and different parser libraries may even disagree in subtle ways.

The same config written in YAML usually looks cleaner:

server:
  host: 127.0.0.1
  port: 8080

feature:
  enable_cache: true

06 TOML: a balance between readability and determinism

TOML is often presented as a modern balanced answer.

Its appeal is that it combines some of the directness of INI with some of the type clarity of JSON:

support for comments
clear structure
stronger, more explicit typing
more natural handling of common types such as date and time
far fewer of the implicit-conversion traps common in YAML

It has also become increasingly common in modern toolchains, such as Python’s pyproject.toml.

Of course it is not perfect. For deeply nested structures, TOML can become verbose, and path-style writing can feel repetitive. But for small to medium project config, tool config, and package-management config, its overall experience is often very steady.

If you want a format with comments, clear meaning, and low parser pain, TOML is a very strong candidate.

A common TOML example looks like this:

[server]
host = "127.0.0.1"
port = 8080

[feature]
enable_cache = true

07 `.conf` and Apache config: not a universal format, but a domain language

One point that is worth emphasizing is that many people see .conf and assume it is a single standard format. It is not.

.conf is just a filename suffix for “configuration.” What the contents look like depends entirely on the specific system’s own rules. In other words, .conf is more like a broad category than a standard syntax.

Take Apache config as an example. Its style is very representative:

part of it looks like single-line directives
part of it looks like tagged blocks with scoped behavior
and it fits very naturally in the domain of web servers

Its strengths are practical for operations work, especially when expressing permissions, routing, and virtual hosts. The downside is that it serves its own ecosystem and does not have much general-purpose portability.

That makes it closer to a domain-specific language: great in the system it was designed for, but not something to treat as a universal config format.

For example, a minimal Apache-style config looks more like a directive list:

Listen 80

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot "/var/www/html"
</VirtualHost>

08 Protocol Buffers: industrial-strength typing, but with a higher barrier

Protocol Buffers are not really “just write a config file by hand” anymore. They are closer to a formal data definition and serialization system.

Their strengths are substantial:

strong typing
explicit schema
good forward and backward compatibility
compact binary transmission
efficient machine processing

But the costs are equally clear:

you need to define .proto files first
you need tools and a compilation step
and the barrier is relatively high for small projects

So they are not ideal when you just want to configure a small tool. But if you are building large systems, RPC services, distributed systems, or long-lived data protocols, they are often far more reliable than lightweight config formats.

Their style is closer to “define the structure first, then generate code”:

syntax = "proto3";

message ServerConfig {
  string host = 1;
  int32 port = 2;
  bool enable_cache = 3;
}

09 In the AI Agent era, Markdown may become a config format again

The most interesting part of this discussion is putting Markdown into the category of “config formats.”

From a traditional programming perspective, that sounds strange, because Markdown normally feels more like a documentation format. But if the target is no longer a rigid parser and instead a large language model or AI Agent, the argument actually makes sense.

Why?

Because traditional programs depend on strict syntax and fixed fields, while large models are much better at understanding meaning, structure, and context. For them:

headings are hierarchy
lists are steps
bold text is emphasis
natural language itself can carry rules

So when the target of configuration changes from “a rigid parser” to “an agent that can understand meaning,” then Markdown, as a human-friendly structured text format, may actually become a more natural kind of configuration.

That leads to a very important judgment: in the traditional software era, many config formats existed to make humans adapt to machines; in the AI era, machines are beginning to adapt to human expression instead.

For example, task configuration for an agent might simply be written like this:

# Goal

Write a welcome email for a new user.

## Requirements

- Friendly tone
- No more than 150 words
- Mention the product's 3 core features

## Forbidden

- Do not promise features that do not exist
- Do not use exaggerated marketing language

10 So how should you choose?

If we compress the whole discussion, I would group the choices roughly like this:

if you want extremely simple, lightweight, flat config: INI
if you want strong structure, strong validation, and legacy compatibility: XML
if you want network transmission and interface exchange: JSON
if you want high readability plus cloud-native and deployment config: YAML
if you want a steadier modern general-purpose config experience: TOML
if you want domain-specific internal rules: .conf / Apache-style DSLs
if you want industrial protocol design and long-term evolution: Protocol Buffers
if you want natural expression and task orchestration for AI Agents: Markdown

So there is no single “best config file format.” It depends on who you are writing for:

humans maintaining the system
machines parsing at high speed
services communicating with each other
or AI Agents that need to understand and execute

Short conclusion

The history of config files is, at its core, the history of humans and machines constantly renegotiating where the cost of understanding should sit.

In the past, humans had to adapt to machines, so we had to memorize brackets, indentation rules, quotes, and rigid syntax. Now that large language models and agent systems are getting better at understanding natural expression, “configuration” itself is beginning to change.

Perhaps in the future, many config scenarios will no longer revolve around one fixed syntax, but around structured statements of intent. Until then, formats like JSON, YAML, TOML, INI, and XML will continue to coexist, each occupying the role that fits it best.

Build Docker Images in VS Code on Windows: From Setup to Build

Thu, 16 Apr 2026 10:20:00 +0800

If you want to build Docker images directly from VS Code on Windows, the workflow is straightforward. You only need three parts: prepare the environment, create a Dockerfile, then run the build.

01 Prerequisites

Make sure these two items are ready:

Install and run Docker Desktop.
Install the official Microsoft Docker extension in VS Code.

On Windows, using the WSL 2 backend in Docker Desktop (Settings > Resources > WSL Integration) is usually more stable and faster.

02 Prepare a Dockerfile

If your project does not have one yet, VS Code can generate it:

Open your project folder in VS Code.
Press F1 or Ctrl+Shift+P to open the Command Palette.
Run Docker: Add Docker Files to Workspace.
Choose your platform (Node.js, Python, .NET, etc.) and follow the prompts.

You will typically get at least:

Dockerfile
.dockerignore

This gives you a working baseline that you can refine later.

03 Three Ways to Build the Image

Method A: Right-click Dockerfile

In the File Explorer, right-click Dockerfile, select Build Image..., and enter an image tag.

Method B: Command Palette

Press F1, run Docker: Build Image, then select context and tag.

Method C: Integrated Terminal

`1`	`docker build -t your-image-name .`

This command builds an image from the current directory context with the tag your-image-name.

04 Quick Checks for Common Issues

Docker Desktop is not running: verify it is started.
Build is very slow: check whether WSL 2 backend is enabled.
Build cannot find files: ensure your terminal is at the project root and files are inside build context.
Docker resources do not show in VS Code: restart VS Code and check Docker CLI (docker version).

Summary

Building Docker images in VS Code on Windows is mostly a setup problem. Once Docker Desktop and the VS Code Docker extension are in place, you can generate Docker files quickly and build images from either the UI or the terminal.

CH347 Resource Guide: Drivers, Tools, and SPI Flash Programming

Fri, 03 Apr 2026 10:00:00 +0800

This post summarizes the CH347 resources I use most often, with one goal: get you from setup to debugging/programming as quickly as possible.

If you are new to CH347, prepare your environment in this order:

Check the official product page first
Install the correct driver for your use case
Prepare an SPI Flash tool and verify connectivity

Official Entry

CH347 product page: https://www.wch.cn/products/CH347.html

It is best to download from the official page first, to avoid outdated or unknown-source driver packages.

Common Drivers

1) `CH341PAR.EXE`

Purpose:

USB-to-JTAG / SPI / I2C / Parallel / GPIO interface driver

Typical use:

Multi-protocol communication and low-level interface debugging with CH347

2) `CH343SER.EXE`

Purpose:

Vendor Windows driver for high-speed USB-to-Serial

Typical use:

Using CH347 mainly as a serial tool, especially at higher baud rates

SPI Flash Programming Tool

AsProgrammer: https://github.com/nofeletru/UsbAsp-flash

Common tasks:

Detect SPI NOR Flash
Read chip ID
Back up original firmware
Erase / write / verify firmware

Recommended Workflow (to avoid common mistakes)

After installing drivers, replug the device and confirm detection in Device Manager.
Before first write, do one full read + backup of the original contents.
Always run verify after writing. Do not rely only on a “write successful” message.
If the chip is not detected, check power, voltage level, and wiring before checking software settings.

Quick Troubleshooting

Device is plugged in but not visible in tools: usually driver loading issues, or a power-only USB cable.
Device is detected but read/write fails: first check wiring order, shared ground, and power stability.
Unstable behavior at high speed: lower read/write speed first, then increase gradually after stability is confirmed.

Summary

CH347 is not hard to use. The key is to get four things right: driver, tool, wiring, and verification.

The resources above cover most beginner and day-to-day maintenance scenarios, and should get you to a stable workflow quickly.

FFmpeg `-map` Explained: Precisely Select Video, Audio, and Subtitle Streams

Thu, 02 Apr 2026 23:14:03 +0800

In multi-audio and multi-subtitle workflows, -map is one of FFmpeg’s most important and most frequently misused options.

If you don’t explicitly specify -map, FFmpeg auto-selects streams using default rules, and the output is often not what you expect. For example:

Subtitles disappear after export
The wrong language track is selected
Unwanted data streams are included

This article uses common real-world scenarios to explain how -map works.

First, Understand What a “Stream” Is

A container file (such as mp4 or mkv) usually contains multiple streams, including:

Video streams (v)
Audio streams (a)
Subtitle streams (s)
Attachment/data streams (fonts, cover art, chapters, etc.)

You can inspect streams with ffprobe:

`1`	`ffprobe -hide_banner input.mkv`

Basic `-map` Syntax

Most common pattern:

`1`	`-map input_index[:stream_type][:stream_index]`

Examples:

0:v: all video streams from the 1st input
0:a:0: the 1st audio stream from the 1st input
1:s:1: the 2nd subtitle stream from the 2nd input

Notes:

input_index starts from 0, based on -i order
stream_index also starts from 0

Practical Examples

1) Video from A, audio from B

ffmpeg -i english.mp4 -i french.mp3 \
  -map 0:v:0 -map 1:a:0 \
  -c:v copy -c:a aac \
  french.mp4

Meaning:

Use the first video stream from english.mp4
Use the first audio stream from french.mp3
Merge into french.mp4

2) Keep all streams from input 1, then add one more audio track

ffmpeg -i english.mp4 -i french.mp3 \
  -map 0 -map 1:a:0 \
  -c copy \
  english-french.mp4

Meaning:

-map 0 keeps all streams from the first input
Then append the first audio stream from the second input

Two Useful Advanced Tricks

1) Negative mapping: exclude unwanted streams

For example, keep everything from input 1 but remove its second audio stream:

`1`	`ffmpeg -i input.mkv -map 0 -map -0:a:1 -c copy output.mkv`

2) Optional mapping: don’t fail when a stream is missing

If some files may not have subtitles, use ?:

`1`	`ffmpeg -i input.mp4 -map 0:v -map 0:a -map 0:s? -c copy output.mp4`

0:s? means: map subtitles if present; otherwise skip without error.

Common Pitfalls

Once you use -map, FFmpeg stops automatic stream selection, so you must map everything you need.
-c copy only remuxes without transcoding. If the target container doesn’t support a codec, it still fails.
With multiple inputs, index mistakes are common. Input indices are determined only by -i order.
For robust scripts, inspect with ffprobe first, then generate -map dynamically.

Summary

The core idea of -map is simple: explicitly tell FFmpeg which input to use, what stream type to pick, and which stream index to select.

Once you master this, you can reliably handle complex cases like multi-audio, multi-subtitle, and cross-file stream composition.

How to Troubleshoot High VS Code CPU Usage Caused by Extensions

Wed, 01 Apr 2026 00:00:00 +0000

When VS Code suddenly feels laggy, your fan spins up, and CPU usage stays high, the most common cause is usually not the editor itself, but extension conflicts or abnormal extension behavior.

This guide gives you a direct, actionable workflow to identify the issue quickly.

Start with the Fastest Method: Start Extension Bisect

Start Extension Bisect uses a binary search approach: in each round, VS Code temporarily disables half of your extensions and restarts. Based on whether the issue still appears, it narrows down the suspect list quickly.

Steps:

Press Ctrl+Shift+P (macOS: Cmd+Shift+P) to open the Command Palette.
Run Start Extension Bisect.
After each restart, check whether high CPU usage and lag are still present, then choose Good now or This is bad.
After several rounds, VS Code will show the likely problematic extension(s).

What to Do After You Find the Suspect

Once you identify the extension, handle it in this order:

Update the extension to the latest version.
If the issue remains, disable it for 1-2 days and observe.
If alternatives exist, switch to a lighter extension.
If you must keep it, review advanced settings and disable unnecessary real-time analysis, indexing, or file watching features.

Two Common “Amplifiers” You Might Overlook

Even if an extension is the root cause, these settings can amplify CPU load:

Search scope is too broad
If build output, dependency folders, and logs are included in global search, extensions and indexers may stay under continuous heavy load.
File watching includes huge folders or symlinks
Symlinks, cache directories, and generated folders can trigger large numbers of file events and force extensions to reprocess repeatedly.

You can trim scope in settings.json, for example:

{
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true
  },
  "files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/node_modules/**": true,
    "**/dist/**": true
  }
}

Postmortem Tip

After isolating the issue, record three things: extension name, trigger scenario, and final fix.
That note will save time when you migrate your environment or rebuild your machine later.

Summary

For high VS Code CPU usage, the most effective path is to use Start Extension Bisect first, then tighten search and file watching scope.
Locate first, optimize second. It is faster and more reliable than randomly disabling many extensions.