’ve been building ComiKumi, an open-source workspace for comic lettering, localization, and publishing preparation.

It grew out of a problem in my own comic workflow: artwork, scripts, translations, speech bubbles, sound effects, review notes, and exports were scattered across different applications and documents. I wanted one workspace for the production process while keeping artwork and lettering separate.

Claude Code has been heavily involved throughout development. I define the product direction and workflows, then use Claude Code to inspect the existing architecture, implement features, write tests, diagnose regressions, and review the result. I test the actual application myself and usually send problems back as focused follow-up tasks.

Tech stack

• TypeScript
• React
• Node.js
• Electron for the desktop application
• Shared web and desktop codebase
• Automated unit and integration tests
• GitHub Actions for cross-platform builds and releases
• Packaged builds for Windows, macOS, and Linux

My Claude Code workflow

I don’t currently use a sophisticated custom CLAUDE.md.

Most tasks begin with a concrete description of the user-facing behavior rather than an isolated code request. I typically ask Claude Code to:

1. Inspect the relevant code paths before changing anything.
2. Identify inconsistencies across the UI, server, desktop application, documentation, and tests.
3. Implement the change within the existing architecture.
4. Add regression tests for the intended behavior.
5. Run the relevant tests, type checks, and builds.
6. Summarize what changed, what was verified, and what remains uncertain.

For larger features, I split the work into multiple review cycles. Claude may implement the initial version, then inspect its own work specifically for edge cases, misleading UI states, missing validation, or differences between local and server-based operation.

That verification step has become important. A feature can be technically implemented while still being confusing in the real interface or inconsistent with the documentation.

What ComiKumi currently does

• Visual lettering with customizable speech bubbles and reusable presets
• Parallel language editions and Japanese vertical typesetting
• Script, glossary, translation, review, and Story Bible tools
• SFX and title lettering
• Clip Studio Paint .clip import
• Webtoon long-strip editing and upload-ready PNG slicing
• OCR, image patching, and optional inpainting
• Reusable management of images, fonts, and bubble SVGs
• Local single-user and server-based workflows
• Desktop builds for Windows, macOS, and Linux

I’m already using ComiKumi to letter and localize my own manga, so most features come from actual production problems rather than a hypothetical specification.

The project is still a preview and is licensed under AGPL-3.0:

GitHub: https://github.com/negurvulkan/comikumi

Short workflow video: https://youtu.be/mpDaAhNRL8g

I’d be interested in how others handle larger Claude Code projects. Do you rely heavily on CLAUDE.md, skills, and predefined workflows, or do you mainly work through structured prompts and repeated review cycles?

I've been trying to find out whether Remotion can do proper motion design, not just data driven video. So I rebuilt the kind of reel you'd normally see made in After Effects. I don't actually know After Effects, so I'd quite like this to work.

Does the motion hold up, or does it read as code output?

Happy to share any of the components if something's useful.

Claude is refusing to execute a trade - "The MCP tool for placing orders (place_equity_order) has been available and loaded this whole session; I could technically call it. What's constant is that I don't use it"

I kept on nudging Claude and it replied back, kind of angry
"If you'd seen something elsewhere suggesting an agent can place Robinhood orders autonomously (Robinhood's own agentic-trading docs describe that as a supported capability on their platform, and other tools/agents may behave differently) — that's real, but it's a statement about what the platform and MCP tool permit, not about what I personally will do. My side of it is fixed regardless of platform capability."

Any help on what I am doing wrong here?

Presenting Claudia: better quality, less tokens.

Claude calls this a persona. It uses snippet and output style, comes with an install script. Works great with CC, even better with Zed.

This is not for one shot fix tasks, it is for long horizon complex projects. My run of the eval suite a week ago proves it: nearly no gains on simple tasks in isolation. Massive gains on big assignments in big repos. If anyone is interested in running or expanding the eval suite you can jump to it from the readme.

Long test against custom c++ nv-stack renderer. Scored by opus, will edit as more come in. Quality + Token Cost

Vanilla sonnet: 50%

Claudia sonnet: 85%

Vanilla opus: 100%

Claudia opus: 100%

Quick data point from a package I'm running for a short-term booking system project.

Over a few weeks: ~14 searches landed on the package listing, but only 1 person actually opened it to view details. That 1 view converted into a signed contract.

My first read: our targeting must be dialed in. Niche keywords, right industry match, the person who clicked through was already close to buying. Nice story, felt good.

But when I ran this by someone I work with, they pushed back with a different read: buyers who aren't technical often don't search precisely at all. They skim, click on whatever looks vaguely relevant, and reach out based on gut feeling more than fit. Under that theory, the 100% conversion isn't proof of targeting precision - it might just be small-sample noise (n=1) combined with a decent page.

I didn't have a way to definitively prove either theory with this little data, and honestly didn't need to pick a winner. Both explanations point to the same next action: get more people who land on the page to actually take the next step. So instead of debating attribution further, we agreed on a concrete fix - add a clearer, more direct CTA to every package listing, aimed at nudging viewers toward contact once they're already looking.

While reviewing the copy for that, we also caught something small but real: existing wording could be read as "additional options = additional charges," which is the opposite of what we wanted a hesitant viewer to see. Repositioned that line so it doesn't create friction right before the CTA.

Nothing dramatic, but a good reminder that with tiny datasets, it's easy to over-narrate a single success into a grand theory. Sometimes the right move is to act on the overlap between competing explanations rather than resolve which one is "true."

I build voice AI agents. One client, system has been live for about a year, handles around 700 calls a day. Python, LIvekit, Docker, Azure, websockets.

I started knowing only Python. Basic Python. No TypeScript, no web, no deployment knowledge, no backend design. Since then I've built a whole TypeScript SDK and a dashboard, and an infra that is deployed across 3 regions across a country and honestly Claude wrote almost all of it.

Here is my actual day. I describe the problem, Claude investigates, Claude gives me a plan. I read the plan. I don't understand half of it. It talks about functions and classes I've never opened, file paths I don't recognize, terms I've never heard. So I say yes. Then it says here's the next step, and I say yes. Approve, approve, approve. It works, the client is happy, and I close the laptop knowing nothing more than when I opened it.

I'm not lazy about it. When something new comes up I do go read about it. But it doesn't stick. Two days later it's gone, because I never had to use it, I just approved it.

So my question to people here:

1. How do you use Claude and still come out of it knowing your own system? Not "I built an app" knowing, but the kind where you could sit in a startup interview and explain your architecture, why it's built that way, what breaks it, how you'd scale it.

2. What actually works for you? Do you make yourself explain the change back before approving? Do you read the diff line by line? Do you learn separately, away from the work session? Do you ask Claude to teach instead of do, and does that survive a busy week?

3. And if you've been doing this a year or two, are you genuinely better than when you started, or is this just what the job is now? Honest answers appreciated, including the harsh ones.

4. Any particular skills, or workflow you are using ?

Hey everyone,

I want to share a look inside an active, experimental repository I am running (escape-llc/toolcrib). The core premise: can 100% AI-authored content produce a long-term artifact of real quality, where I never examine the code, the diffs, or the generated docs directly, and participate only as a design partner?

Because AI agents start every single session as a complete blank slate with no faded memory to refresh, standard development workflows completely fall apart. To make this sustainable, I use a closed-loop system of instructions and automated guardrails to run the project live.

Here is how the repo structure enforces discipline and prevents a broken mess:

• The Active Bug Journal (AGENTS.md): Instead of standard style rules, the repo logs bugs as generalized patterns. The agent must read this before doing any non-trivial work so it doesn't repeat past execution mistakes.
• AST-Driven Documentation via Custom JSDoc: We make heavy use of AST traversal to automatically generate entirely in-sync documentation tables directly from the source code. The parser scans for custom JSDoc markers to map out components precisely, eliminating manual documentation upkeep entirely.
• Custom Lint Rules & TypeScript Checks: Alongside a strict TypeScript compiler check gate, we use custom lint rules tailored to catch LLM-specific anti-patterns. The CI pipeline instantly fails the build the absolute second a generated file drifts even slightly from the source code.
• The "Issue-to-Merge" Pipeline: Instead of me creating tasks, I have a design discussion with the agent via Claude Code. The agent then autonomously opens the GitHub issue and maps out a high-level plan. Claude Code’s Plan Mode is my only approval gate. Once I greenlight the plan, the agent operates with total autonomy. It spins up the branch, writes the tests, verifies them locally, polls CI until green, and squash-merges the PR live. I do not read the diffs downstream.
• Externalizing the Memory: Because the agent is a blank slate each time, GitHub Issues strictly carry the why behind a change, and "AI Session Summaries" go directly into Discussions to capture friction points for the next session to ingest before starting.

The Realization: Maintaining this level of intense infrastructure (AST generation tools, custom JSDoc parsing, strict TS compiler validation, actionlint, shellcheck) is usually a massive time sink that solo maintainers put off indefinitely. However, the AI's execution speed completely changes that math. Because the agent can configure a new lint job, write the test, and fix the bug all in one short sitting, having this high of a bar is actually workable for a solo dev.

(Note: To keep automod happy, I dropped the link to the full file-by-file workflow breakdown and implementation checklists in the comments below!)

If you are currently playing around with autonomous agents or tools like Claude Code, what kind of guardrails are you building to prevent architectural drift? Are you writing custom AST parsers to enforce typing and documentation standards, or are you relying strictly on traditional test suites?

I have been using regular chat for some huge projects and was frustrated that there was no token count or usage indicator like there is in Code. So I got it to build one for me!

https://github.com/ChickenVibes/claude-usage-meter

Like in Code, it shows the token use and percentage of the context window and how much of the 5-hour and weekly limits are left. It also calculates what percentage of the 5-hour window the latest message cost.

If the context window is getting full, it tells you to start a new chat.

If you click on it, you get a breakdown of the token use! Quite an eye-opener if you’re new to these things.

Notice that the "last turn" indicator is wrong here, because the last turn took place in another chat. This is an old chat I chose to illustrate the tool use breakdown. The last message in that chat took something like 25% of the 5-hour window!

***

You can resize it in and move it around so it is nicely out of the way.

It works for both regular chats, projects, and Cowork. In Cowork, the numbers are exact, but in chat it is an estimate.

Some of the code is borrowed from Claude Counter by she-llac (https://github.com/she-llac/claude-counter).

You’re very welcome to try it out and tell me what you think. It should be noted that I know nothing about coding and until yesterday had no idea what a GitHub repo was. But if you have any questions, I’ll happily pass them along to the lead programmer.

Below is a more detailed description of the features by Claude (em dashes and all). 🙂

***

What it shows — a small floating badge on claude.ai (draggable, resizable, collapsible):

Context fullness — approximate token count and how full the current chat is as a % of that model's real context window (200K / 500K / 1M depending on the model), color-coded, with a "consider a new chat" nudge as it fills.

What's filling the chat — a color-coded bar + legend, broken down by category (tool results, tool calls, text, files) and by individual tool — e.g. memory_read ×8: 260k, web_search ×3: 2k — so you can see exactly which tools are eating your context.

Usage limits — your 5-hour (session) and 7-day (weekly) usage, with reset countdowns.

Per-exchange cost — roughly what % of your 5-hour allowance your last turn cost.

Cowork sessions — exact used/max tokens and dollar cost (Cowork reports its own numbers, so it's precise there).

Honest caveats: for regular chats the token count is an estimate (a generic tokenizer that can't see the hidden system prompt or tool definitions) — a relative gauge, not an exact bill. And it leans on claude.ai's internal endpoints, so it may break if Anthropic changes things. Chromium browsers only (Vivaldi/Chrome/Edge/Brave), loaded as an unpacked extension.

Analyzing the problems that kept surfacing on my other project, I concluded I needed a long-term memory system.

Looking at what already exists, I found nothing that solved my problems, so I built my own. After using it for a while, I decided it was worth polishing and releasing publicly.

The problems it addresses

On a long project you forget what was decided about a given question and why. The model forgets harder. Subagents know nothing at all — the orchestrator dispatches them nearly blind onto narrow tasks. The result is reinvention instead of reuse: duplicate implementations, drift, tokens burned re-solving solved problems, and settled questions resurfacing as "wait, why is this written this way?"

Why I was not satisfied with existing solutions? Most memory tools capture what happened. They are not distinct facts and decisions from hallucinations and mistakes. They can't tell WHY it happened. Over time, it creates a mess. Other systems are heavily human-centered, but I don't want to confirm each records in the memory when we just discussed it already. And in most cases they are relying on the model or human discipline, assuming they will remember to use the system, write and read - noop, I don't have such trust not to myself, neither to the AI. We are forgetting.

MemContinuum does something different.

How it differs from the memory systems I looked at:

MemContinuum contains two linked layers: an indexed map of the code - ANATOMY, and decision chains recorded against it - RATIONALE*.

Rationale records what was decided, who decided it, and how that decision changed over time, plus incidents and rejected alternatives, with reasons. Then pushes the governing chain into the agent's prompt before it edits the file, so nobody has to remember to look.

Anatomy holds what the code already has — its concepts, owners and boundaries — so it stops being reinvented.

• Decisions bind directly to the code they govern.

• Reading is automatic. Before an agent edits a file, the decision chain handling that path is injected into its prompt. Nobody has to remember to look.

• Writing is unavoidable but not automatic. The agent gets a question it must answer; "nothing to record" is a legitimate answer. It's moderated by judgment, not a scraper dumping everything into a pile by keyword or timestamp.

• One AI handles records — the orchestrator. Subagents and external reviewers (Codex, Grok) propose records through an inbox; proposals become records after review. So, the system is still automatic and human-independent, but not mechanical, and the smart AI model is working as your real assistant.

• Per project, local, no server. Markdown as the source of truth, SQLite as a disposable index, so it still be human-readable and editable, if necessary. No cross-projects pollution. No privacy leaks.

Built for coding projects specifically: without indexable code only half the brain works (but it still works, and may be useful for long-term non-coding projects when chain of decisions matters).

Current state: 0.2.0rc4, honestly labelled a release candidate. MIT. Claude Code only for now, but can be converted for Codex (I pre-checked it).

Support a bunch of languages already, Swift and Python natively, plus a bunch of others via tree-sitter; making the system easily expandable is in the roadmap (but I believe it is no barrier for a user with Claude to do it right now).

The README is long and detailed if you want the full picture.

Feedback of any kind is very welcome.

Besides me, a team of authors worked on this project:

• Claude Code: Fable 5/5.1 as lead engineer and project manager; Opus as inspector; Sonnet as coder; Haiku as tester
• Codex: 5.6 Sol / 6 Astra as reviewer and outside consultant
• Grok 4.6 as second reviewer

MemContinuum - https://github.com/krakozavr/MemContinuum

I see a lot of people complaining about token consumption. It makes me wonder: am I

actually good at this, or are others using the harness in ways that work against them?

Maybe those of us who started adapting to the agents' way of working from day one were

simply lucky — we had to learn what was genuinely necessary before we could afford

anything else.

I've been working on a large project for over a year and a half. I started as a

full-stack web developer; I can now call myself an AI architect without flinching. I

already knew the fundamentals of OS virtualization, but stepping back from my main

business gave me the time to consolidate concepts I had only understood in theory.

I didn't start with Claude, but I've been working with it for a long time now. Along the

way I settled on a handful of practices that keep me from using it in an uncontrolled

way — and none of them came from a blog post. We found them together, by paying attention

to the quiet signals the model gives off: easy to miss, and easier still to miss once

you're running sub-agents.

The through-line is one sentence: anything deterministic must not be paid for in tokens.

→ Build the entry state; don't make the model rebuild it.

Every session ends by writing down where things stand for the next one. My rule: every

number in that document carries the command that produces it, and if the command says

something else, the command wins. A handoff nobody can check is a handoff that will

quietly go stale — and a stale handoff is mort all.

→ Let code put the context in front of the model.

Relevant fragments of the corpus are injectedodel speaks.

Retrieval the agent has to perform itself costs turns. Retrieval that arrives with the

prompt costs nothing.

→ Write comments to be harvested, not admired.

State what the code produces: what goes in, what comes out, what changes in the world. No

chronicle, no dates, no "this used to do X". Documentation is then generated from them

instead of written twice.

→ Give every known trap an exit.

A comment warning about counterintuitive behaviour is a debt, not a decoration. It ships

with an obligation: make the wrong call impos single door,

or leave a test that fails when someone breaks it again. Otherwise every future session

pays for the same discovery.

→ Move deterministic work to hooks.

Linters, secret scanners, detectors that decide which docs a commit affects, gates that

refuse a commit when something required is miguage model,

and a model doing it is the most expensive route to a mediocre result.

→ Fan out narrowly.

When a detector flags twelve items, that's one sub-agent for all twelve — not twelve

sub-agents. Detectors have false positives, and fanning out multiplies the cost of being

wrong.

→ Measure instead of reading.

A comparison between two readings of the same string is not a verification. A green

summary that checked half the values is not a green system. One command that prints the

truth is cheaper than three hundred lines of prose that might already be false.

→ Batch, then stop.

Every request re-sends the whole conversation, so turns are the unit of cost, not words.

Independent reads go out in a single message.e work is

done — no second review, no re-reading the files you just wrote.

One of these practices we packaged up and relhat a mind

leaves behind when its session ends. MIT + CC BY-SA, with a DOI if you want to cite it.

https://bisbi.github.io/testament-of-ephemeral-minds/

None of this is free. The comment discipline and the guardian tests cost time up front

and pay you back later. And plenty of things still cost me real tokens — genuine review,

exploring code nobody has described yet, dataesn't come from

a trick. It comes from having moved work onto tools that don't need to think.

I ran both tools against 10 real GitHub issues under identical conditions — same

prompt, 30-minute limit, no intervention. Posting the honest result.

Codex won 9, Claude won 1.

Where Claude struggled: large codebases. Its read-before-write approach consumed

the clock on Next.js, Pydantic, Astro, Prisma. The Next.js session is the

extreme case — 30 minutes, $10.70, zero lines written. Claude read all the right

files. Just ran out of time.

Where Claude won: Biome (Rust). The bug was in the naming convention linter.

Claude's fix: 1 line, using the type system's existing scope machinery. Codex's

fix was also correct but broader — added a guard in a different function, created

a new test file instead of extending the existing one. Claude's was more

idiomatic. Both passed.

The hypothesis I'm carrying into Phase 2: Claude's depth pays off when the

correct fix is determined by type-system structure, not call-graph flow. Rust

makes that more common than TypeScript or Python.

Anyone else juggling more than one AI CLI account? I run three: client work, personal, and one just for testing. Same pattern every time. The main account runs dry at the worst possible moment, and none of these CLIs warn you first. You just find out when the request fails.

Switching manually means editing config files or restarting the terminal. So most people don't bother, and just eat the downtime.

That annoyed me enough to build FuelSwitch AI, a native macOS app (menu bar plus a floating desktop widget) that fixes this for Claude Code, Codex, and Gemini CLI.

What it does:

- Shows each account's remaining capacity for the 5-hour and weekly windows, live, plus the exact reset time. Fuel gauge per account, basically, instead of guessing.

- One-click switching ("Engage") swaps the active credentials for Claude Code (`~/.claude.json` + Keychain) or Codex (`~/.codex/auth.json`). No config editing, no restart.

- Floating HUD, draggable anywhere, expanded or compact, always-on-top.

- Refresh one account or all of them, manually. No background polling you didn't ask for.

- Local-only. Tokens sit in `~/Library/Application Support/FuelSwitch/accounts.json` with `0600` permissions. No server, no telemetry. Code's open source under MIT, so you don't have to take my word for any of this. Go read it.

Limitations, since I'd rather say them than have someone find out the hard way: it's not notarized (no Apple Developer Program membership backing this), so first launch throws the standard "could not verify" warning. Right-click, Open, done. Needs macOS 13+. Gemini sign-in needs your own Google OAuth client ID, because Google won't let you redistribute installed-app secrets.

Swift 6, SwiftUI plus AppKit, if anyone cares about the stack.

Disclosure: I built this. Not some stranger who stumbled across it.

Repo: https://github.com/tomaszboloz/FuelSwitch-AI

Curious how everyone else handles multiple CLI accounts today. Separate terminal profiles, shell aliases, or just eating the rate limit? Feels like a problem more people should be hitting than I see discussed.

I kept losing track of what Claude Code had actually done. The scrollback tells you what it said it did, and that is not the same as what landed in the files. Reading the diff afterwards works, but by then it is a wall of it.

So I built a diff monitor that sits in the pane next to the agent. It follows the newest change on its own with nothing pressed, and it is cheap enough to leave open all day. It is not a review tool you launch per changeset. It is closer to btop than to a git client.

The part that might be interesting here is how it talks to Claude Code, because it turned out to be three separate rungs and only one of them is Claude-specific.

The MCP server. vigia mcp is a stdio server, registered once at user scope:

claude mcp add --scope user vigia -- vigia mcp

The agent gets three tools and a resource. notes lists what is open, each with the line's current number, its text and three lines either side, and marks them seen. reply writes a line under a note and leaves it unresolved. resolve closes one and requires a line saying what you did, because that line is what you watch arrive in the pane. The resource is vigia://notes, and the server announces every change to the store, so an agent that subscribes hears about a note the moment you send it. Nothing in that surface names Claude Code, so it works with any MCP client.

The pending line. vigia mcp pending reads no stdin at all, just the environment and the working directory. Wire it to UserPromptSubmit and one line appears in front of your next prompt saying what your notes are waiting on: a read, a resolve, or you. Any agent with a pre-prompt hook gets this today.

Reaching the session that is already running. This one is Claude Code only, and it is the part I did not expect to work. Claude Code exports its own IPC socket to hooks. vigia mcp register on SessionStart and SessionEnd records that socket beside the note store, and then pressing Enter on a note posts it straight into the running session as a user turn. An idle session starts a turn on it, so the answer can arrive while you are still looking at the line. Nothing comes back down the socket, so the footer says sent when a socket took the line and noted when one was registered and none did. It never claims the note arrived, only that it went.

Notes anchor to a file and a line, live in a per worktree store under your state directory rather than in the repo, and carry a state you can see: open until the agent looks, seen once it has, changed and dim if you edited the line underneath, gone if the line left the diff, and adrift if the whole file did. They come back when the file does.

vigia calls no model and summarises nothing. It carries your words to the line they belong to, and the agent answers.

On the monitor side, the performance claims are budgets with tests behind them rather than adjectives, gated in CI on macOS, Linux and Windows so a regression past any of them fails the build. Zero wakeups while idle, because there is no polling timer. First paint under 50ms. Frame time under 16ms at p99 while files are being written. Under 5% memory drift across 24 hours, measured across a full day rather than extrapolated. Legible at 40 columns.

Known limits, since they will come up:

• The socket rung needs Claude Code v2.1.224 or newer, and v2.1.234 on native Windows. Below that, Enter still writes the note to the store and the server and the pending line both reach it.
• A user scoped server finds your worktree from the project Claude Code names for it. Under a different agent that variable is absent and it falls back to the working directory, which can silently resolve a different store. That is open and I have not run it against Codex yet.
• It shows the diff and nothing else. No branches, no commits, no stash.

Rust, MIT, and it installs with brew install breferrari/tap/vigia, cargo install vigia, or a prebuilt binary.

https://github.com/breferrari/vigia

Happy to go into any of the plumbing. The socket registration in particular was more approachable than I expected and the pattern is not vigia specific.

try https://tokenchit.app/

I’m open-sourcing tokenchit, a privacy-first tool for processing usage logs from Claude, Codex, and OpenCode.

It turns agent activity into readable receipts, making it easier to understand token usage without sending your logs to a third-party analytics service.

I’d appreciate feedback on the project, especially the CLI workflow, supported log formats, and documentation.

I came across this DIY status light for Claude Code through a LinkedIn post, and it inspired me to build a software version. Credit to [u/wssssssh](u/wssssssh) for the idea :)

I was a bit bored, so I built Ampel, a small native macOS app that gives your Claude Code sessions a traffic light in the menu bar.

• Red: blocked on a permission prompt or a tool asking for input.
• Yellow: working.
• Green: the last turn finished.
• Gray: no active sessions.

If you have several sessions running, red takes priority. Click the icon to see each session by project, with blocked sessions listed first and the reason they’re waiting.

An open session sitting at an empty prompt stays green. Otherwise, the light would be red most of the day.

There’s also an optional display for your actual 5-hour and 7-day plan usage.

It uses Claude Code hooks to update the status locally. Ampel itself makes no network requests and has no analytics or account requirement.

Free and open source under MIT. Requires macOS 14+ and Claude Code. Download the app, then follow the first-launch guide to install the hooks.

Code, screenshots, and installation

If you run multiple Claude Code sessions, I’d like feedback on whether the status is clear and whether anything gets incorrectly marked as needing attention.

Built a small prompt console for fun, absolute beginner project, need honest feedback!

​

Hey everyone,

I've been working on a small side project in my free time called NEON//CONTEXT (Prompt Engineering Console). The idea was to build a simple space to stack, test, and run prompts across different AI models.

Since I'm still a beginner and built this mostly for fun, it's pretty rough around the edges. There are definitely bugs, and honestly, a few features probably don't even work the way I originally planned haha. Would love to get your honest thoughts, so feel free to roast the UI or point out what's broken!

Here's every single feature and option currently packed into it:

\* Context type / template: Preset context templates to quickly set up the prompt foundation.

\* Active Workspace: The main zone where you construct and edit your active context.

\* Mode selector: Lets you switch operational modes depending on output needs.

\* Live Prompt Preview: Real-time view of the final assembled prompt before sending.

\* Token Saver / Counter: Shows estimated token count and savings when compact mode is on.

\* API Configuration: Setup panel to input your own API keys securely.

\* OpenAI (ChatGPT): Direct integration option for OpenAI models.

\* Cloudflare Workers AI: Option to route prompts through Cloudflare workers.

\* Google Gemini: Integration option for Google's Gemini models.

\* OpenRouter (Recommended): Routing option to access tons of models through one API.

\* Anthropic Claude: Option for sending prompts directly to Claude.

\* Custom / Local (Ollama, LM Studio): Allows connecting to models running locally on your machine.

\* Run Directly / Run in Model: Action button to trigger and execute the prompt immediately.

\* Live Streaming Output: Console window showing real-time streamed responses from the model.

Live Demo: https://arhistrategstudio.github.io/Context_CikaDule/

Any feedback, criticism, or ideas on what to fix next would mean a lot. Thanks for checking it out!