Forem: Charles Zhang

DevLog 20260319: Metaprogramming (Teaser)

Charles Zhang — Thu, 19 Mar 2026 20:16:19 +0000

Quick Comment

Following Document-Level Main Module, the possibility really opens up...

This is very different from our earlier hard-coded "Stats" node.

DevLog 20260319: Towards OOP - Document-Level Default Module and Module-Level Members and Behaviors

Charles Zhang — Thu, 19 Mar 2026 20:16:08 +0000

Revisiting Flappy Bird – The Pain Point

Remember our Flappy Bird example from mid-2025?

The long chain of variable initializations was needed for two main reasons:

No way to declare variables before using them
More critically - no way to define custom data structures that could group related values together and be instantiated with a single node.

In retrospective it seems obvious: we just need proper structured data containers. But building the scaffolding to support this properly in a visual, node-based system is a bit more involved.

Searching for a Solution

I spent a long time trying to bring OOP concepts into Divooka. A huge amount of effort went into DiOS (Divooka Open Standards), with the hope that a complete standard would naturally solve these kinds of problems. But standardization work is slow and deep - just like making Divooka itself feature-complete.

Then, while working on something completely unrelated and taking a short break from this topic, it suddenly clicked.

The key insight: start simple and approach it from a functional/declarative angle first, before jumping into inheritance, encapsulation, polymorphism, and all those good stuff.

I'm really excited - we finally have meaningful progress.

The Divooka Way

To claim our goal as "everything is a node" is a bit too strong, but I strongly prefer keeping almost everything on the graph.

This aligns with how we already handle structured primitives - direct value setting of compound inputs. That way, there's still hope that users can drop down to raw node programming when they need full control (and thus keep everything programmable).

Traditional property panels (like Unreal Blueprints' object definition GUIs) are out - they break the pure graph paradigm.

Instead, the solution is declarative, similar to how TerraGen works: the mere presence and connection of certain nodes defines meaning.

This feels awesome for several reasons:

We can make full use of the 2D graph layout - place things exactly where we want them visually
It stays completely coherent with Divooka's graphical paradigm
No need for separate "class editor" UIs

What's Been Implemented So Far

Current working pieces:

Graphs can now act as modules
Support for module-level data members and behavior members
A main module tied to the document, with existing graphs serving as associated behaviors

Module-scoped instance node – in Events context

Module-scoped instance node – in Dataflow context

Top-level module behavior graphs

This immediately unlocks:

Clean access to (top-level) module instances
Shared event and dataflow instance data
A unified programming and document model for subgraphs (still a work-in-progress)
In procedural contexts (Glaze! especially): we now have proper data containers - no more awkward giant variable lists or forced tuples! (Compare to the old Flappy Bird screenshot)
Much simpler and more natural state storage/access in Glaze! and procedural graphs

This is a big deal - for a system that's gearing up for real production use, it feels like crossing a major milestone in usefulness and core abstractions.

Current Limitations & Remaining Work

Still plenty to fix/polish:

A bunch of bugs and edge cases
Proper serialization support
Smooth context switching between graphs
Subgraph consolidation / better nesting UX

Looking Ahead

This is a solid foundation, but there's still a long road:

Full modularization support
Modules inside modules (nesting)
Module inheritance / composition patterns / polymorphism
Base DOM exposed as the "main module" for metaprogramming API
Detailed documentation: how it all fits together, recommended usage patterns, expected behaviors, pitfalls
Module-level scoped instances (deeper/finer control)

Overall - I am very happy with the direction. It feels like Divooka is finally getting the abstraction power it deserves while staying true to its visual, graph-first philosophy.

I am hyped for what we will achieve.

References

A Detective Story: The Case of The Dead Office Guy (Upcoming Game Release)

Charles Zhang — Fri, 06 Mar 2026 19:29:11 +0000

Overview

In the quiet town of Baytown, an unremarkable man lies dead under suspicious circumstances. Rumors ripple through the streets. Secrets long buried begin to surface. The whole community is buzzing - some in dread, others gripped by dark fascination.

A Detective Story is a compact detective simulator that brings generative AI to the heart of interactive fiction.

Step into the role of detective in this small-scale murder investigation. Interrogate a cast of AI-powered townsfolk, each with their own motives, fragmented memories, and the potential to lie or mislead. Explore the map to uncover physical evidence and hidden clues. Piece it all together before time runs out.

Game Guide

Your mission: Solve the murder as efficiently as possible - minimize days elapsed and questions spent.
Bringing suspects to the station costs valuable time (days). Choose your interviews with care.
These are informal interrogations - no formal oaths, no truth serum. Witnesses and suspects may deceive, omit, or hide the truth.
You have only 3 questions per interview. Make every one count.
Stay in character for maximum immersion: Ask about alibis, relationships, timelines, strange sightings, and contradictions.
Cross-check stories, hunt inconsistencies, and link conversations to evidence found on the map.

Hardware Requirements

A Detective Story is lightweight and runs smoothly on modest hardware. It requires at least 10 GB of system RAM (DRAM) - with no heavy VRAM demands.

DevLog 20260225: Divooka Visual Programming - Direct Value Setting of Compound Inputs

Charles Zhang — Wed, 25 Feb 2026 17:46:45 +0000

Finally, it arrived! Well, not exactly here yet, but getting closer.

Overview

Divooka intends to make visual programming simple and accessible - the accessible part is achieved both through wide availability and the general-purpose nature of the programming system, but the simple part is what we spend lots of effort thinking hard trying to improve.

In the past, dealing with complex configuration takes the form of either "explosion" of arguments or dedicated Make XXX construction functions:

The problem arises due to the direct exposure of all input arguments in visual programming. Both approach makes the canvas look busy, with the former a common approach in existing systems - using a struct sounds good on paper but still requires a complex looking construction node. This is a common problem in visual programming systems, below shows how it's done in Blender and ComfyUI.

You do get used to it after a while, but a busy looking canvas remains a busy-looking canvas. In Blender, you can sort of "collapse" a node:

As Blender is constantly improving, we can also now collapse property groups as shown in the earlier screenshot.

As a syntax purist and (unfortunately) very conscious about my working space, my eyes can't tolerate messiness. I kind of like how Houdini approaches this.

Essentially they offload all the complexity to the properties panel - this has the huge benefit of making everything look very clean. But the downside is Houdini rely heavily on scripting expressions (like Excel).

TerraGen and World Machine mixes the approach:

In both cases, connections represent flow of terrain data only and additional configurations are offloaded to property panels. In TerraGen especially, this allows those properties to be animated. The downside, once again, is whatever is offloaded to property panels are no longer programmable using nodes.

Our Approach

Our proposed solution for Divooka looks like this: fundamentally all properties remain as node inputs, but compound values (especially value types) should just allow "editing in place" through a property panel. If more complex programming is needed, one can easily fall back to Make XXX nodes again.

Future Work

There is still remaining work on type check, hierarchical compound types, arrays, and serialization, and also node rendering.

Conclusion

As usual with all the exciting language features of Divooka we intend to introduce, there are lots of details to take care of here.

DevLog 20260224 Divooka - Node-Level Automatic Dispatch (Runtime Execution Behavior)

Charles Zhang — Tue, 24 Feb 2026 22:20:52 +0000

Overview

Anything useful done with a program eventually involves file I/O and some form of repetition.

In Divooka, the dataflow context already makes it very easy to "just get a single thing done." That part feels good. But handling loops? That's where things start to get awkward.

One challenge lies on the GUI side — especially around lambdas and subgraphs. We do have foundational support (as shown here and here), but let's be honest: it's not smooth yet.

So the question becomes: how do we make repetition feel natural without introducing heavy conceptual overhead?

The Plan

There are several well-established ways to achieve looping behavior in a functional or visual programming context:

Subgraph context - Used in tools like Blender, vvvv, and Houdini. A specialized node group or frame defines loop entry and exit boundaries.
Lambda callbacks - Evaluation is handled via callback-style execution.
Expressive recursion - As seen in text-based functional languages, requiring explicit termination conditions to avoid stack overflow.

All of these approaches are powerful and necessary in certain contexts. But they also introduce additional constructs into the language model. For advanced workflows, that's fine. For simple operations, it can feel unnecessarily complex.

I wanted something lighter.

Array Coercion

Divooka already supports Array Coercion — a scalar value can be passed into an input expecting a collection.

This avoids the need to manually "wrap" a scalar into an array just to satisfy a function signature - I still remember the pain of handling arrays in Unreal Blueprint.

Scalar-to-array coercion keeps graphs clean and avoids clustering.

To take this to the next level, I've been giving it much thought on how the reverse might work: if we can coerce scalars into arrays — what if we also let nodes automatically dispatch when arrays are passed in?

Automatic Dispatch (Node-Level)

The core design question was:

Should an array input implicitly turn the entire downstream chain into a loop?
Or should the dispatch behavior stay localized to the node itself?

Eventually it seemed localizing things to the node made far more sense.

For example:

string String.Replace(string, string, string)

If any input is provided as an array instead of a scalar, the node automatically promotes itself to:

string[] String.Replace(string[], string[], string[])

The node executes element-wise.

Now, I can rename a folder of files with roughly three nodes:

Enumerate files
Regex replace
Rename file

No explicit loop node. No subgraph. No lambdas.

In this example, Duplicate as Array returns a strongly typed string[], enabled by generics support.

One important rule: All array inputs must align in size with the source array. The dispatch is index-based and deterministic.

Full Example

What used to require explicit iteration logic now becomes implicit behavior at the node boundary. The graph remains readable. The mental model stays simple.

Conclusion

This is still early work. Integration with the rest of Divooka's features is ongoing, and edge cases are being worked through.

So far so good.

DevLog 20260122: Some Notes on MAUI, Unity, and Building "Map-Like" App Across Platforms

Charles Zhang — Fri, 23 Jan 2026 02:48:08 +0000

I've been meaning to write about this topic for a while.

MAUI looks great on paper. In fact, it has looked good on paper for years. Microsoft went a long way through UI and application frameworks: VBA, WinForms, MFC, WPF, Silverlight, UWP, Blazor, and now MAUI. Each iteration promises unification, abstraction, and better productivity over platform differences.

My first attempt at MAUI felt deceptively easy. I gave up shortly after.
So did the second attempt.

This time was different: I had a concrete delivery target. Giving up was no longer an option.

The Problem: A "Map-Like" Feature

The concrete requirement was simple to state but not easy to implement well: an app with a map-like feature. Not a full GIS stack, but something that looks and behaves like a map - large static textures, panning, zooming, overlays, and user interaction. No library - we are going to implement things from ground up.

My first instinct was to go cross-platform. After years of writing platform-locked GUIs that die the moment requirements change, I had no interest in repeating that mistake.

After surveying a wide range of options - inside and outside the C# ecosystem - I narrowed the choices down to:

Unity
Godot
MAUI

I tried Unity first.

Unity: Smooth Onboarding, Rough Reality

Unity deserves credit where it's due. It was the first mobile platform I ever used seriously, and I had already developed an Android game with it years ago.

Coming back with significantly more experience in C#, general software engineering, and game development, the onboarding felt excellent. The editor is mature, the documentation is decent, and the mental model is comprehensible.

Within about three days, I felt comfortable again - comfortable enough to implement the prototype. The implementation itself was straightforward (details skipped here), but the result was not.

On an actual Android device, performance was terrible. Given time pressure, I didn't fully chase down the root cause. A few hours of profiling and hypothesis testing later, I made the call to bail. Whether the issue was overdraw, batching, UI layout, or just the wrong API for the task didn't matter anymore - the risk was too high. (Oh, did I mention the build size was gigantic?)

I would have liked to include some demo code - at least the Unity version - but time didn't allow for it. That will have to wait for another post or a future amendment.

MAUI: Dry, and That's a Compliment

Rewriting the same idea in MAUI worked. Not "worked eventually" - it worked immediately and predictably. (Actually I tried Expo before MAUI, which was very smooth, then I looked at the hundreds of dependencies, and quietly reconsidered)

That forced me to rethink a long-held assumption (something I had from the CG world): engines optimized for real-time rendering should be good at texture-heavy workloads. In practice, frameworks optimized for application UIs are often better at static or semi-static content - especially when the interaction model looks more like "pan and zoom" than "render 60 FPS no matter what."

MAUI was dry. I wasn't excited to see its "mobile-like" layout on a Windows screen, and I still am not.
But dry was exactly what the project needed.

The Hidden Cost

That said, this experience didn't magically make me like MAUI - and that reminds me of Blazor.

The core issue in both cases is structural. These frameworks attempt to abstract over domains whose constraints diverge in important, non-accidental ways. The abstraction holds only as long as the application stays within a relatively narrow envelope of complexity.

MAUI Issues

Cross-platform inconsistencies are everywhere, not edge cases.
iOS AoT compilation and trimming can cause things to silently stop working.
Many behaviors that should be easily configurable (for example, disabling the Flyout) require platform-specific code.
Debugging failures caused by trimming or linker behavior is disproportionately painful.

Blazor Issues

Refactoring is far harder than it should be.
Large component trees quickly become rigid.
Abstractions that feel elegant early on tend to resist change later.

In both cases, the abstraction breaks - and when it does, you're often forced to drop down into platform-specific or framework-specific escape hatches that defeat the original promise.

These frameworks scale poorly in complexity, not because they are badly designed, but because they attempt to simplify domains that fundamentally resist unification. (Well, honestly in the case of MAUI I do think there are some design issues)

In general, MAUI is slightly better, because it's at least well encapsulated - just write platform-specific codes.

Some Takeaways

Game engines are not automatically good UI frameworks. Application frameworks may outperform engines for static, interaction-heavy visuals. In this particular case I haven't tried Godot, but I suspect the same issue wouldn't happen to Godot.
"Write once, run anywhere" really means "debug everywhere." And don't expect MAUI can save you effort because platform-specific behaviors are everywhere and it took me lots of time to back trace which seemingly trivial change many commits ago caused the entire application to break; Or, just turn off the magic MtouchUseLlvm.
MAUI is an OK choice for simple cross-platform mobile apps in C#.
Unified frameworks seem to trade short-term velocity for long-term friction. In the perfect world, I will use Swift for iOS.

In general, I wish framework developers make it clear their limitations so decision making can be made upfront.

Weekly Update 2026-01-11

Charles Zhang — Mon, 12 Jan 2026 01:29:00 +0000

This week was mostly about tightening up the foundations of our tools rather than pushing new features. A lot of our older experiments were starting to show their age, so we spent time cleaning things up and getting the core systems into better shape.

What Happened This Week

Refactoring Neo + Parcel NExT review

We continued working through refactors on Neo and reviewing the Parcel NExT implementation. Some of the earlier experimental frontend work had spread across multiple assemblies, so small API changes ripple everywhere. Slow, but necessary.

WPF + Nodify wrestling

A surprising amount of time went into understanding how WPF resource dictionaries, theming, and Nodify's API actually want to behave together. After digging through the quirks, we finally have a clearer picture of how to keep styling and view models consistent. Didn't get as far into custom styling as we hoped, but at least the fundamentals are sorted out.

Serialization groundwork

Started wiring up the basics for text-based JSON serialization of Divooka graphs/documents. Also began work on package reference records and figuring out how packages get identified and loaded at runtime. All early steps, but important ones.

Graph editor + GUI cleanup

Made some initial passes at reorganizing the graph editor. Small changes now, but they'll help us build better tools on top later.

Fantasy Planet Painter update

Spent a little time polishing and updating the Steam submission for Fantasy Planet Painter.

Methodox Threads

We also pushed out an early public release of Methodox Threads, our lightweight branching text environment for managing non-linear AI conversations. The new v0.7 build adds integrated Gen-AI generation directly inside each document pane, configurable providers, and a simple JSON-backed structure for exporting or versioning thought trees. It's essentially a cleaner way to explore tangents, run parallel prompts, and keep complex LLM work organized. Download is available on itch.io.

Closing Thoughts

Not a "big features" week, but a surprisingly productive one in terms of future stability. Refactors aren't glamorous, but they make everything that comes next a lot smoother.

Release Note: Methodox Threads (v0.7)

Charles Zhang — Mon, 12 Jan 2026 01:14:34 +0000

Overview

Version 0.7 introduces full Gen-AI generation capabilities, including per-document prompt-driven content generation, provider configuration, OpenAI integration, and asynchronous multi-editor execution with UI-level busy indicators. This release establishes the foundation for a extendable, multi-provider LLM workflow while maintaining the existing document layout and editing model.

New Features in v0.7

Configurable AI Provider Framework

A new Configure… dialog provides a unified interface for system-level and provider-specific settings:

System Tab

Edit the global System Prompt used for all generations.

OpenAI Tab

API key (masked)
Optional custom endpoint
Preset model list:
- gpt-4o-mini
- gpt-4o
- o3-mini
- Other → reveals a custom model name field
Support for model overrides when presets become outdated
Automatic load/save of configuration in a user-specific app directory

Additional provider tabs (Gemini, DeepSeek, Ollama, Grok) are included as placeholders for future integrations.

Gen-AI Generation Workflow

Each document now supports prompt-based content generation:

Users set a Prompt on any document.
Selecting Edit → Generate triggers generation for the focused document.
Generation uses:
- Global System Prompt
- Document Prompt

Per-Editor Async Generation

Each document editor generates independently in parallel.
Editors become temporarily read-only during generation.
A semi-transparent overlay displays Generating… with an indeterminate progress bar.
Sibling/Child creation buttons remain active.
Generated text is written directly into the document’s Content field.

OpenAI Integration (First Provider Implementation)

A new abstraction layer encapsulates provider calls.
Version 0.7 includes the first concrete backend:

OpenAI Chat Completion Backend

Uses the official OpenAI SDK.
Supports both default and custom endpoints.
Converts internal document structures into Chat API messages.
Returns full assistant text as document content.

This abstraction enables drop-in integration of additional providers in future versions.

Configuration Persistence

All provider and system settings are automatically stored as JSON in the user-local app directory:

Loaded when opening the Configure dialog
Saved on dialog close
Ensures persistent environment across editor sessions

Limitations

No document deletion or rearrangement
Markdown preview remains basic
Only OpenAI is implemented; other providers are placeholders
Generation does not yet stream partial output

References

Introducing Methodox Threads: Tame the Chaos of Branching AI Conversations

Charles Zhang — Mon, 12 Jan 2026 01:13:12 +0000

Tired of losing brilliant tangents in endless LLM chats?
Frustrated when editing a prompt wipes out your entire history, or when long threads become impossible to navigate?

You're not alone. Every generative AI user - from casual brainstormers to researchers, writers, and prompt engineers - hits the same wall:

Linear chat interfaces simply weren't built for nonlinear thinking.

That's why we built Methodox Threads.

Threads is a linear-yet-branching text environment crafted for managing complex ideas and AI conversations - especially those that naturally fork into tangents, nested explorations, and parallel paths.

And with the new v0.7 release, Threads becomes more than an organizational tool. It a generative workspace for chat management.

Core Experience at a Glance

Multi-pane, tree-like layout Each document lives in its own dedicated, scrollable editor. The whole structure remains visible, so you can see the big picture while diving deep into any branch.
Natural branching From any node, spawn siblings (parallel directions) or children (deeper explorations). Build clear, persistent hierarchies without losing context.
Integrated Gen-AI generation (new in v0.7!) Add a Prompt to any document and generate AI-assisted content directly into that pane. Includes:
- Per-document generation
- Parallel, asynchronous execution
- Read-only “Generating…” overlay during output
- Global system prompt
- Configurable AI providers (OpenAI available now; Gemini, DeepSeek, Ollama, Grok coming soon)
- Custom API endpoints and custom model names
- Secure, auto-saved per-user configuration Your entire AI workflow now runs inside the branching editor itself.
Iteration-friendly writing environment Full Markdown editing, inline notes, JSON/Markdown export, and a distraction-free dark UI. Refine AI outputs, rewrite prompts, annotate ideas - without ever resetting a thread.
Portable & future-proof A clean JSON structure under the hood, with markdown Gen-AI folder import/export support for v0.6+ projects. Version-control your thought trees with ease.

Threads lets you shape AI conversations the way your mind naturally works: branching, revisiting, exploring alternatives, and layering insights - all without friction.
Picture exploring what-ifs in a worldbuilding document, generating multiple stylistic takes side-by-side, or running parallel reasoning chains for research - all visible at once, never buried in scrollback.

For a deeper dive into the design motivations and architecture, check out our dev log “Motivations for Methodox Threads”.

Get Started

Threads is available now as an early public release from Methodox Technologies.
Download it today and start turning chaotic AI interactions into structured, generative thought trees.

→ https://methodox.itch.io/threads
→ Follow @methodox for updates, tips, and early access to upcoming provider integrations, streaming AI output, and full multi-model workflows.

Introducing Methodox Threads: Tame the Chaos of Branching AI Conversations

Charles Zhang — Mon, 12 Jan 2026 01:13:12 +0000

Tired of losing brilliant tangents in endless LLM chats?
Frustrated when editing a prompt wipes out your entire history, or when long threads become impossible to navigate?

You're not alone. Every generative AI user - from casual brainstormers to researchers, writers, and prompt engineers - hits the same wall:

Linear chat interfaces simply weren't built for nonlinear thinking.

That's why we built Methodox Threads.

And with the new v0.7 release, Threads becomes more than an organizational tool. It a generative workspace for chat management.

Core Experience at a Glance

Multi-pane, tree-like layout Each document lives in its own dedicated, scrollable editor. The whole structure remains visible, so you can see the big picture while diving deep into any branch.
Natural branching From any node, spawn siblings (parallel directions) or children (deeper explorations). Build clear, persistent hierarchies without losing context.
Integrated Gen-AI generation (new in v0.7!) Add a Prompt to any document and generate AI-assisted content directly into that pane. Includes:
- Per-document generation
- Parallel, asynchronous execution
- Read-only “Generating…” overlay during output
- Global system prompt
- Configurable AI providers (OpenAI available now; Gemini, DeepSeek, Ollama, Grok coming soon)
- Custom API endpoints and custom model names
- Secure, auto-saved per-user configuration Your entire AI workflow now runs inside the branching editor itself.
Iteration-friendly writing environment Full Markdown editing, inline notes, JSON/Markdown export, and a distraction-free dark UI. Refine AI outputs, rewrite prompts, annotate ideas - without ever resetting a thread.
Portable & future-proof A clean JSON structure under the hood, with markdown Gen-AI folder import/export support for v0.6+ projects. Version-control your thought trees with ease.

For a deeper dive into the design motivations and architecture, check out our dev log “Motivations for Methodox Threads”.

Get Started

Threads is available now as an early public release from Methodox Technologies.
Download it today and start turning chaotic AI interactions into structured, generative thought trees.

→ https://methodox.itch.io/threads
→ Follow @methodox for updates, tips, and early access to upcoming provider integrations, streaming AI output, and full multi-model workflows.

DevLog 20260110: Motivations for Methodox Threads - A Conversation Management Tool

Charles Zhang — Sat, 10 Jan 2026 20:02:39 +0000

Hey folks, Charles here from Methodox. As a developer deeply embedded in the generative AI space, I've spent the last couple of years wrestling with the limitations of LLM interfaces. Today, I want to dive into the motivations behind our latest project, Methodox Threads - a linear, branching text environment built to tame the chaos of long, tangled conversations. This isn't just another note-taking app; it's a structured canvas designed for iterative thinking, especially when collaborating with AI models. I'll keep this log developer-focused, touching on the architecture and implementation choices, while highlighting why this solves a universal pain point for anyone using gen AI tools.

The Problem: Chaos in Conversation Management

If you've ever dived deep into a conversation with an LLM like Grok, ChatGPT, or Gemini, you know the drill: things start linear, but soon you're branching into tangents, exploring "what-ifs," and iterating on ideas. The trouble? Existing interfaces suck at handling this complexity.

OpenAI's ChatGPT: They pioneered branching, which is a step up, but in long threads, navigation becomes a nightmare. Scrolling through endless history to find that one pivotal response? Forget it - context gets buried, and resuming a branch feels like archaeology.
Grok (xAI): The side navigation pane is a nice idea on paper, but in practice, it falls flat for multi-branching. Creating parallel explorations requires awkward workarounds, and the UI doesn't scale for deep hierarchies.
Gemini (Google): Editing a prompt erases the previous version entirely - no versioning, no undo. It's like the tool assumes your first draft is always perfect, which is laughable for creative or analytical work.

Worse still, none of these platforms let you edit the AI's responses natively. For developers doing prompt engineering or users in creative writing, this is a deal-breaker. You spot an inconsistency or want to tweak for better flow? You're stuck regenerating from scratch, praying the model stays consistent (spoiler: it often doesn't). OpenAI's Canvas tries to address iterative editing, but it's hampered by the underlying AI's memory lapses and lack of true state management.

This isn't just a dev gripe - it's a widespread issue. Casual users brainstorming ideas, researchers tracking hypotheses, or writers building narratives all hit the same wall: conversations sprawl, branches get lost, and productivity tanks. In a world where gen AI is democratizing creativity, we need tools that empower structured exploration without the friction.

My Journey: From Hacks to a Dedicated Tool

I've been hacking at this problem since the early days of gen AI. Inspired by tools like Kobold AI (which excels at local, scriptable story generation), I started building lightweight local management systems. Early prototypes used simple folder structures to mimic threads - each "branch" as a subfolder with text files for prompts and responses. Others adopted custom JSON formats for serialization, allowing easy versioning via Git.

These worked okay for personal use but lacked visual intuition. Exporting/importing conversations was manual, and scaling to nested tangents felt clunky. That's how I conceived Methodox Threads: born from my startup's focus on AI-enhanced workflows, it's a purpose-built app that evolves these ideas into a robust, user-friendly system.

From a dev perspective, Threads is architected around a tree-like data model (think hierarchical nodes in a graph database, but lightweight and in-memory for speed). Each node represents a thread segment:

Core Structure: A root document spawns children (nested explorations) and siblings (parallel branches). This is implemented with a recursive node class in our backend (built on Avalonia for cross-platform desktop use), easily exportable to JSON format.
UI Layout: Multi-pane editors, each fully scrollable and synchronized. We use a canvas-based layout with customizable pane width and height and automatic height adjustments for children documents - useful when dealing with deep hierarchies of varying complexities.
Features for Iteration:
- Markdown support via a lightweight parser (no rendered preview at this moment, but syntax highlighting is a work in progress).
- Document-wise notes and project README for meta-commentary (e.g., "This branch assumes v2 prompt").
- Project serialization to JSON or export to Markdown in folders, making it Git-friendly for version control.
Distraction-Free Design: No bloat - just a clean canvas. You can create branches either from the menu or through the hover buttons; In the future we may provide keyboard shortcuts for branching (e.g., Ctrl+B for new sibling) and drag-and-drop reorganization, drawing from IDEs like VS Code.

The goal is to enable deep dives without losing the forest for the threads. For general users, this means organizing a chatbot session on "world-building for a sci-fi novel" into branches like "Character Arcs," "Plot Twists," and "World Lore" - all visible at a glance. For devs, it's a playground for prompt chaining, where you can fork a thread to test API variations without derailing the main flow.

Why Build This?

At its core, Threads addresses the cognitive load of unstructured AI interactions. Gen AI users - whether hobbyists or pros - crave persistence and flexibility. Developers like us need it for debugging prompts, prototyping agents, or managing multi-model experiments (e.g., comparing Grok vs. GPT outputs side-by-side). The general public benefits from a tool that makes AI feel less like a black box and more like a collaborative partner, especially in fields like research, writing, or ideation.

We're charging a very small courtesy cost to support the continued development of this tool, since developing such an interface is easy for anyone with GUI dev experience - but continuously improving it is what makes it truly usable.

Future Plans: From Manual to Seamless AI Integration

Right now, Threads is a powerhouse multi-pane text editor, but populating it requires manual copy-pasting from your LLM of choice. That's fine for bootstrapping, but we're gearing up for true integration.

API Endpoints First: We'll start with the OpenAI API, allowing users to "continue" a thread by sending the full branch context plus a system prompt. Imagine right-clicking a node and selecting "Query GPT" - it appends the response as a child node, preserving history.
Prompt Engineering Tools: Built-in templating for system prompts.
Multi-Model Support: Expand to Grok, Gemini, and local models via Ollama. Devs can plug in custom endpoints.
Version Control Friendly Exports: Exporting to scattered Markdown files is very useful since internally many older conversations were archived this way and it looks nicer on Git diff than JSON.
AI-Assisted Structuring: Use lightweight ML to suggest branches or summarize threads (like how Grok works).

We're iterating fast so file formats and exact usage pattern may change, and will spend more time on this if receive plenty user interest. If you're a dev interested in sharing ideas or a user with feedback, hit us up at Methodox (contact@methodox.io). Stay tuned for more updates!

Let's make AI conversations manageable for everyone.

References

DevLog 20251216: Supporting Multiline Input in Pure

Charles Zhang — Tue, 16 Dec 2025 14:31:14 +0000

Make things much easier.

Currently you cannot go back, so it's pretty preliminary.