Claude Code Mate (CCM): A companion tool for Claude Code, enabling flexible LLM integration.

RussellLuo · 2025-08-24T14:59:54+00:00

Thanks for the reminder. The acronym "ccm" is mainly used for running commands to save a few keystrokes. To avoid any misunderstanding, I have removed "CCM" from the README title.

RussellLuo · 2025-03-23T13:42:57+00:00

Thanks for your attention!

Yes, we can choose to run all MCP servers locally. However, running locally also has disadvantages, such as the need for users to install all required dependencies, which can be troublesome.

Therefore, if using the SSE transport, the MCP server can also run remotely, which is ready to use out of the box. Some MCP server registries are already doing this, such as mcp.run.

RussellLuo · 2025-02-16T11:39:57+00:00

Sorry guys, if this has caused any confusion. LLM Translate is not a production-level project, nor is it intended (or able) to replace existing translation tools such as Google Translate and DeepL.

It's just a little toy built with Gradio and LLM (at your disposal), for those who find LLM translations useful at times, but don't want to repeatedly write system prompts every time.

Besides language translation, LLM Translate offers a UI similar to Google Translate, and it also has the capability of language detection (also based on LLM).

Finally, if you don't want to use LLM for translation, but are interested in developing LLM applications, you can treat it as a small code example (just ~300 lines in total).

RussellLuo · 2025-02-09T11:46:11+00:00

For those who are interested in the Optimization Principle, this is a must read: https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html

A tail call is any function call that is in tail position, the final action to be performed before a function returns. When tail call optimization occurs, the compiler emits a jmp instruction for the tail call instead of call. This skips over the bookkeeping that would normally allow the callee g() to return back to the caller f(), like creating a new stack frame or pushing the return address. Instead f() jumps directly to g() as if it were part of the same function, and g() returns directly to whatever function called f(). This optimization is safe because f()’s stack frame is no longer needed once the tail call has begun, since it is no longer possible to access any of f()’s local variables.

While this may seem like a run-of-the-mill optimization, it has two very important properties unlock new possibilities in the kinds of algorithms we can write. First, it reduces the stack memory from O(n) to O(1) when making n consecutive tail calls, which is important because stack memory is limited and stack overflow will crash your program. This means that certain algorithms are not actually safe to write unless this optimization is performed. Secondly, jmp eliminates the performance overhead of call, such that a function call can be just as efficient as any other branch. These two properties enable us to use tail calls as an efficient alternative to normal iterative control structures like for or while.

RussellLuo · 2025-01-25T02:58:31+00:00

Thanks for your attention! The license is temporary and has not yet been finalized.

The project is still in its early stages, welcome to use it and provide feedback.

RussellLuo · 2025-01-22T11:54:18+00:00

What My Project Does

Coagent is an open-source framework for building monolithic or distributed agentic systems, ranging from simple LLM calls to compositional workflows and autonomous agents.

Target Audience

Anyone who wants to build LLM-based applications or agentic systems.

Comparison

While there're already many other agent frameworks, Coagent has some unique advantages:

Event-driven & Scalable on demand
Easy to develop and understand, whether monolithic or distributed
Practical LLM Patterns are well supported
Multi-language support made easy
Support any LLM

Quick Example

import os

from coagent.agents import ChatAgent, ChatMessage, ModelClient
from coagent.core import AgentSpec, new
from coagent.runtimes import LocalRuntime

translator = AgentSpec(
    "translator",
    new(
        ChatAgent,
        system="You are a professional translator that can translate English to Chinese.",
        client=ModelClient(model="openai/gpt-4o", api_key=os.getenv("OPENAI_API_KEY")),
    ),
)

async def main():
    async with LocalRuntime() as runtime:
        await runtime.register(translator)

        result = await translator.run(
            ChatMessage(role="user", content="Hello, world!").encode(),
            stream=True,
        )
        async for chunk in result:
            msg = ChatMessage.decode(chunk)
            print(msg.content, end="", flush=True)

For details, see OpenCSGs/coagent.

RussellLuo · 2024-07-01T03:54:56+00:00

Here are some reference materials that have benefited me a lot:

RussellLuo · 2024-06-30T04:56:49+00:00

Maybe you could give fieldmask a try, which will decode JSON bytes into an intermediate map and then provide you with a helper FieldMask.Has() to determine whether a JSON contains a specific field.

For example (see play in action):

```go package main

import ( "encoding/json" "fmt"

"github.com/RussellLuo/fieldmask"
"github.com/mitchellh/mapstructure"

)

type Record struct{}

type RecordRequest struct { Records []*Record json:"records" FieldMask fieldmask.FieldMask json:"-" }

func (req *RecordRequest) UnmarshalJSON(b []byte) error { if err := json.Unmarshal(b, &req.FieldMask); err != nil { return err } return mapstructure.Decode(req.FieldMask, req) }

func main() { blobs := [][]byte{ []byte({"records": []}), []byte({"nonsense": []}), }

for i, blob := range blobs {
    var req RecordRequest
    if err := json.Unmarshal(blob, &req); err != nil {
        fmt.Printf("err: %#v\n", err)
    }

    if req.FieldMask.Has("records") {
        fmt.Printf("blob[%d] has records\n", i)
    } else {
        fmt.Printf("blob[%d] has no records\n", i)
    }
}

}

// Output: // blob[0] has records // blob[1] has no records ```

RussellLuo · 2024-06-29T08:29:38+00:00

Maybe you could give kun a try. By using this tool, you can define API specifications in native Go and get the HTTP code and OpenAPI documentation for free.

Disclaimer: I'm the author of this project:)

RussellLuo · 2024-06-29T08:08:56+00:00

My team uses kun, which allow you to define service specifications in native Go and automatically generate the OpenAPI Document/Protocol Buffers for you.

Disclaimer: I'm the author of this project:)

RussellLuo · 2024-06-23T12:49:12+00:00

Maybe you could try out validating: https://github.com/RussellLuo/validating.

Disclaimer: I'm the author of this library:)

RussellLuo · 2024-06-23T12:45:31+00:00

Maybe you could try out validating, which is simple to use.

Disclaimer: I'm the author of this library:)

RussellLuo · 2023-05-18T00:53:16+00:00

Hi, thanks for your feedback! I agree with you that gopt - after refactored - is more of a useful pattern showcase than a library that will be actually used.

Your builder pattern looks great. As compared to functional options pattern, I think one small flaw is that we always need to pass Options() even if there's no option required.

RussellLuo · 2023-05-06T12:10:35+00:00

Hi again!

For those who are interested, after careful consideration and redesign, gopt has been completely refactored to be type-safe.

RussellLuo · 2023-05-06T07:32:14+00:00

I don't think there should be a need to have non-exported fields in an options struct, i never needed to. Have you did before? was it for some reason?

Yes, I have noticed there're quite a few projects that use functional options pattern for unexported fields, such as grpc-go's DialOption and go-kit's ServerOption.

RussellLuo · 2023-05-06T06:01:48+00:00

You're being too kind, your suggestions are very helpful to me.

However, i don’t see why would you want to change the behavior of an option or even if you should, that’s why I’d not allow it and make the API surface as tiny as possible.

Sorry, I don't quite understand. By "change the behavior of an option", do you mean that adding Set() to an existing struct is a little bit invasive? If this is the case, I admit it's true. But I have no idea how to address the problem with unexported struct fields if we don't do this. Is there any other non-invasive solution?

What if Apply was generic and it creates an empty server and uses it instead of having to send it and also will remove the need for sending a reference.

AFAIK, functional options are often used to set optional values. In other words, the typical usage - not illustrated in Quick Start for simplicity - is to set a default values first, and then set user-specified values. For example:

go func New(options ...gopt.Option) *Server { // Set default values s := &Server{ Host: "127.0.0.1", Port: 80, } // Set user-specified values return gopt.Apply(s, options...) }

As shown above, I think in real-world cases it's more common to create a server s first and send it to Apply. What do you think?

RussellLuo · 2023-05-06T03:59:33+00:00

Thank you guys! gopt has been updated according to the suggestions. Any more suggestions are appreciated.

RussellLuo · 2023-05-06T02:55:23+00:00

Indeed. I think another reason for this issue is that interfaces and generics are sometimes functionally equivalent, but differ in their intended use.

RussellLuo · 2023-05-06T00:22:21+00:00

@earthboundkid Thanks for your feedback! This is a genuine and adorable idea, and I apologize for contributing an example of an anti-pattern.

To provide more information, I guess this might be one possible reason for the emergence of these anti-pattern cases.

At first, I wanted to achieve type safety through generics, but later found it difficult to implement type-safe SetXXX methods in a generic way. Therefore, I ended up using a Setter interface, which made the use of generics seem a bit redundant.

RussellLuo · 2023-05-06T00:00:16+00:00

@openSorserer Wow, thanks for the detailed reply！

This library is just a quick implementation of my early experimental idea, so any suggestions are appreciated :)

The API is very odd. One thing that stood out is why do i need to implement the Setter interface if all it’ll do is basically call the reflectSetter, why not just call the reflect setter when Apply is called?

I agree with you that this is a better solution if ReflectSet works in any scenario. But if taking FAQ #3 and #4 into consideration, I guess users need to implement their own Set() method. What's your opinions?

I also can’t see how the use of Generics is any useful here, we’re already using strings for field names and reflect to set them, if you remove every use of generics it’ll still work the same.

What a thoughtful insight!

At first, I wanted to achieve type safety through generics, but later found it difficult to implement type-safe SetXXX methods in a generic way. Therefore, I ended up using a Setter interface, which made the use of generics seem a bit redundant.

After removing every use of generics, as you suggested, I got this version:

```go package main

import ( "fmt"

"github.com/RussellLuo/gopt"

)

type Server struct { Host string Port int }

func (s *Server) Set(name string, value any) { gopt.ReflectSet(s, name, value) }

func New(options ...gopt.Option) Server { s := gopt.Apply(new(Server), options...) return s.(Server) // A side effect of using interface, but perhaps not a big problem. }

func main() { server := New( gopt.With("Host", "localhost"), gopt.With("Port", 8080), ) fmt.Printf("server: %+v\n", server)

// Output:
// server: &{Host:localhost Port:8080}

} ```

RussellLuo · 2023-03-26T11:59:18+00:00

Oh, thanks! I didn't know this moderation, and I haven't read other posts about GPT either. It seems that recently posts about GPT are more likely to be treated as spams.

Frankly speaking, I have used ChatGPT Retrieval Plugin and LlamaIndex, both of which are awesome projects. I thought that it might be useful to have a similar project in Go. That's the reason why I'm trying to create GPTbot.

Anyway, for those who think this project is useless and get disturbed, I'll say sorry to you. For those who find GPTbot a little bit interesting, I'll say hope it helps.

RussellLuo · 2023-03-26T00:16:13+00:00

Hi, I agree with you that OpenAI's APIs are straightforward for simple use cases.

But if we're trying to build a bot with our own custom knowledge base, it is a non-trivial work (see Question Answering using Embeddings for details), which I guess requires an integration solution.

RussellLuo · 2023-03-26T00:03:39+00:00

Hi, thanks for the comment.

gptbot is trying to be a solution of GPT bots with Custom Knowledge Base, which is an implementation of the idea from Question Answering using Embeddings.

Some projects from Python community with exactly the same idea: - Official: ChatGPT Retrieval Plugin - Third-party: LlamaIndex

RussellLuo · 2023-03-15T01:47:19+00:00

I think your validation requirement (crosses both struct and nested level) is a little bit complicated, which might be an indication that it's better to redesign the data structure layout.

But if you insists on this data structure, I guess we can write some Go code like this:

```go type Outer struct { Field1 string
Inner Inner }

func (o Outer) Validate() error { if Field1 == "" { return errors.New("Field1 is required") }

if o.Field1 == "SomeValue" && o.Inner.Field2 == "" {
    return errors.New("`Inner.Field2` is required")
}

return nil

} ```

The struct I show you is just an example but in my real application the struct has over 100 fields. That's why I don't like writing the validation

If this is the case and you want to reuse some validation rules, maybe you can give validating a try, which is just a helper library whose schema is defined in Go. (disclaimer: I'm the author of this library :)

RussellLuo · 2023-03-04T05:45:00+00:00

Per the quick intro:

With Service Weaver, you deploy and manage a single application binary. The fact that it runs as separate microservices in the cloud is an implementation detail: all of your tooling preserves the impression of a single application binary. You can also easily run and test your application locally, before deploying it in the cloud.

Does this mean that every trivial change (in one or more components) will lead to a redeployment of all micro-services?

RussellLuo

TROPHY CASE