Team Account and Project-Based Credit Management

[Juice10]

A user (discord DMs) has suggested the following features for team accounts:

• Credit Limits with Auto-Refill: The ability to set a spending limit for credits, even with auto-refill enabled. This would provide better cost control for businesses.
• Project-Based Credit Logging: The ability to associate credit usage with specific projects. This would be valuable for:
  • Businesses: Billing clients accurately for usage on their projects.
  • Solo Developers: Tracking credit consumption per project to manage costs and resources effectively.

This would be a significant enhancement for both businesses and individual developers using the platform.

[Juice10]

Related: #759

[Juice10]

I would suggest for the project based credit logging we look at the package.json's name field if it exists in the project. And use that as a label to tag usage. That is probably more consistent across team members than using something like folder name for example.

Popular package.json alternatives

---

🟨 JavaScript / TypeScript

• File: package.json
• Field: "name"
• Also look at: "scripts" and "dependencies" to infer framework (e.g., Next.js, React)

---

🐍 Python

• File: pyproject.toml (modern standard) or setup.py (legacy)

• Field:

  • In pyproject.toml: [project] name = "..."
  • In setup.py: name="..." in setup()

• Also look at: [tool.poetry], [tool.pdm], or requirements.txt to identify tools used

---

☕ Java

• File: pom.xml (Maven) or build.gradle(.kts) (Gradle)

• Field:

  • Maven: <name>, <artifactId>, <groupId>
  • Gradle: rootProject.name = "..." or archivesBaseName

• Also look at: dependencies to guess framework (Spring Boot, etc.)

---

🦀 Rust

• File: Cargo.toml

• Field:

  • [package] name = "..."

• Also look at: [dependencies] to identify if it’s CLI, web (Rocket/Actix), etc.

---

🐘 PHP

• File: composer.json

• Field:

  • "name" (typically "vendor/project")

• Also look at: "require" to detect Laravel, Symfony, etc.

---

💎 Ruby

• File: Gemfile or .gemspec

• Field:

  • .gemspec: spec.name = "..."
  • Gemfile often used with Rails; presence of rails gem is a big hint

• Also look at: Rails project? Check for config/application.rb

---

🐧 C / C++

• Files: CMakeLists.txt, Makefile, or meson.build

• Field:

  • CMake: project(<name>)
  • Meson: project('name', 'c')
  • Makefile: often no explicit name, but custom variable like TARGET = ...

• Also look at: structure and included libraries

---

🐍 Go (Golang)

• File: go.mod

• Field:

  • module github.com/user/project — infer name from module path

• Also look at: presence of main.go, cmd/ folders to identify app type

---

🐳 Docker

• File: Dockerfile

• No "name" field, but can infer from:

  • Image name/tag in docker-compose.yml
  • Comments or labels (LABEL name="...")
  • Folder name or GitHub repo name if available

---

🌐 .NET (C#, F#, VB)

• File: .csproj, .fsproj, .vbproj

• Field:

  • <AssemblyName>, <RootNamespace>, or file name itself

• Also look at: <Project Sdk="Microsoft.NET.Sdk.Web"> to detect ASP.NET

---

[baumedr]

Another option would be to have a artefact in the .kilocode directory. Not all projects that are worked on will have a package.json. We work heavily with dotnet for example. The project name can be loaded at folder-open/load-time and used throughout the session, if this is committed, other developers pulling the same code repo will also have the same name automatically so when team billing comes in you have a universal tag to filter on

[Juice10]

That is a good idea and make it flexible for most edge cases

[Juice10]

Possibly the most consistent way of identifying which project is being worked on is by using the git remote in the project. That should be mostly universal across the team and should also be universal across different stacks. Of course there are also other version control systems that we might be able to add support for in the future as well.